From patchwork Thu Feb 22 06:40:31 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steve French X-Patchwork-Id: 1902584 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=kNR6utzw; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org (client-ip=147.75.199.223; helo=ny.mirrors.kernel.org; envelope-from=linux-cifs+bounces-1322-incoming=patchwork.ozlabs.org@vger.kernel.org; receiver=patchwork.ozlabs.org) Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org [147.75.199.223]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4TgNnf1rQfz23hY for ; Thu, 22 Feb 2024 17:40:54 +1100 (AEDT) Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 616831C21613 for ; Thu, 22 Feb 2024 06:40:51 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 27F6B7469; Thu, 22 Feb 2024 06:40:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="kNR6utzw" X-Original-To: linux-cifs@vger.kernel.org Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 57151C8E2 for ; Thu, 22 Feb 2024 06:40:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.181 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708584047; cv=none; b=PWIRxV+iJ8IRDmody8N1kAqvXM7tPnMtyBtEOYdGkKoyZ8FCTCR8TIf7DG33bYZwYWjjkAzgcXGq+7OrVMig9IQaSz/g5SXupY79+zZE3r5iJcVrbalpl6RD9n2WRXt9m9jbTdnaHyibId4+dngJhrzgo5u49qF+11pI8AagiRY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708584047; c=relaxed/simple; bh=8qbDf5r+Lp32ivHPTyddRBGp9CEEjoAS+Qo9YS0wenk=; h=MIME-Version:From:Date:Message-ID:Subject:To:Cc:Content-Type; b=cWN2DqdDjs9feLUIoniIU1zBb03Kao8RbctM4iHNFoeHxW439e5Jb/ath/amHeF4tfhOKXf5A0XM9L43XXis16t0LUS50YGfKqlZHefPZ/hOxcWsBQrOW0Hz1ExZyahYRzmac81kSQj2/GIpgEqEJMnzvWbDnOFSP2ivZOl6WwY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=kNR6utzw; arc=none smtp.client-ip=209.85.208.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lj1-f181.google.com with SMTP id 38308e7fff4ca-2d0a4e1789cso16032791fa.3 for ; Wed, 21 Feb 2024 22:40:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708584043; x=1709188843; darn=vger.kernel.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=Is1Hk8pJRrHgKq2pzPZI4LIXhrl9F/LhHiQKLEGareo=; b=kNR6utzwarK+JBzp4U8YQkw7XSV7KB2FLmj4tzSGt31wJUQUZoay9qdg+dh0jtTZAe TghPkJnsPbhEGyJQIqf0kM8F1wgGnHDkz+cZgdtGaWTye4lehCzsAW8eFeUWRyImc4q6 oeSBv+KnYIK9MJA2sFGv0Q1DwtvnVz7jK93uNPo4QN3FcntzMkIghPBpOnKmR5+iUCOA 86krGyYndz4/8/DtSEXcb74Lh/ENW78/XEOQ6Hat2dsFWjQZNNhonwO3WoRc/ChmeCqu s0zNRcQU6BQyE28vVkS/hZOLihP5/3HZjfNbWI47HLp1V99CLvhfHINERHQxIMkslRGO EPMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708584043; x=1709188843; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Is1Hk8pJRrHgKq2pzPZI4LIXhrl9F/LhHiQKLEGareo=; b=rjoGGDXKjzeKCKlv8z4S/2S5VLCtTa0y7s6s8cwHNdfs6gErtbuepqqKnrXq4RMbOt v5ebautaKjt4HyflkLuHRDl5Fl/EaHTlp6uR6Y3Pi0ORsSt3iFmg4N7NcxYDUr/Hcs3Q XVPHK1pHVvqzfvQyQGTCPKkkq/xx24ivfiOE7A+GuvsFpDFK4I/CKWe+9bUKBYtK1aDw JS6EA6Ar7cgf6TpxV/aSLC+I/NrUeYA4b9AqzzN5u0fCyolVjR822Ts2TKGTN7nYm3kx 9w3MkTYQaNn+AV10wsALlj6PIYGzyWIBmPe+Q6uMhTBlE3Z76uaV9lxRIDJHBycuBWUO /UcQ== X-Gm-Message-State: AOJu0YwBEeKblKCSG4k8DlbcpTIOPPDPJRThXGg8k1JkHb8FA1KhHsCn /2K0ZPWqfkhQWH0mTmi2fhXol8KF0u2tXzPwMbIsqnze5Iubs3ME+RbUhDLFpAEUn63yeSL3iC1 6HPe628krHrr2T2MDrEbFkW1b4/C89jRMZQlx7g== X-Google-Smtp-Source: AGHT+IHQXZxOP9ohz38J//7Gnu4POLd1jWz4klsApGXUawi8i8JkCd+NqBdhgrO+WpD+mRBEfGqw3TI13Bb0MOfccgY= X-Received: by 2002:a2e:b1c9:0:b0:2d2:3f13:52e7 with SMTP id e9-20020a2eb1c9000000b002d23f1352e7mr6006238lja.12.1708584042872; Wed, 21 Feb 2024 22:40:42 -0800 (PST) Precedence: bulk X-Mailing-List: linux-cifs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Steve French Date: Thu, 22 Feb 2024 00:40:31 -0600 Message-ID: Subject: [PATCH][SMB3 client] update allocation size more accurately on write completion To: CIFS Cc: Shyam Prasad N , Meetakshi Setiya , Bharath S M , Paulo Alcantara Changes to allocation size are approximated for extending writes of cached files until the server returns the actual value (on SMB3 close or query info for example), but it was setting the estimated value for number of blocks to larger than the file size even if the file is likely sparse which breaks various xfstests (e.g. generic/129, 130, 221, 228). When i_size and i_blocks are updated in write completion do not increase allocation size more than what was written (rounded up to 512 bytes). See attached. This fixes the recent regression in various xfstests caused by the xfstest change commit b4396efc75aba5325f22690303857af4f63d128e Author: Alexander Patrakov Date: Tue Dec 19 04:57:20 2023 +0800 _require_sparse_files: rewrite as a direct test instead of a black list From ae33f1b691cc9fd6fc0dfe84981e5e8d5f0cd3d2 Mon Sep 17 00:00:00 2001 From: Steve French Date: Thu, 22 Feb 2024 00:26:52 -0600 Subject: [PATCH] smb3: update allocation size more accurately on write completion Changes to allocation size are approximated for extending writes of cached files until the server returns the actual value (on SMB3 close or query info for example), but it was setting the estimated value for number of blocks to larger than the file size even if the file is likely sparse which breaks various xfstests (e.g. generic/129, 130, 221, 228). When i_size and i_blocks are updated in write completion do not increase allocation size more than what was written (rounded up to 512 bytes). Signed-off-by: Steve French --- fs/smb/client/file.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/fs/smb/client/file.c b/fs/smb/client/file.c index 05e915162f05..6b2da368d52d 100644 --- a/fs/smb/client/file.c +++ b/fs/smb/client/file.c @@ -3095,8 +3095,15 @@ static int cifs_write_end(struct file *file, struct address_space *mapping, if (rc > 0) { spin_lock(&inode->i_lock); if (pos > inode->i_size) { + loff_t additional_blocks = (512 - 1 + copied) >> 9; + i_size_write(inode, pos); - inode->i_blocks = (512 - 1 + pos) >> 9; + /* + * Estimate new allocation size based on the amount written. + * This will be updated from server on close (and on queryinfo) + */ + inode->i_blocks = min_t(blkcnt_t, (512 - 1 + pos) >> 9, + inode->i_blocks + additional_blocks); } spin_unlock(&inode->i_lock); } -- 2.40.1