public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Wengang Wang <wen.gang.wang@oracle.com>
To: linux-xfs@vger.kernel.org, david@fromorbit.com
Cc: wen.gang.wang@oracle.com
Subject: [PATCH] xfs: allow changing extsize on file
Date: Wed,  8 May 2024 10:03:43 -0700	[thread overview]
Message-ID: <20240508170343.2774-1-wen.gang.wang@oracle.com> (raw)

Hi Dave, this is more a question than a patch.

We are current disallowing the change of extsize on files/dirs if the file/dir
have blocks allocated. That's not that friendly to users. Say somehow the
extsize was set very huge (1GiB), in the following cases, it's not that
convenient:
case 1: the file now extends very little. -- 1GiB extsize leads a waste of
        almost 1GiB.
case 2: when CoW happens, 1GiB is preallocated. 1GiB is now too big for the
        IO pattern, so the huge preallocting and then reclaiming is not necessary
        and that cost extra time especially when the system if fragmented.

In above cases, changing extsize smaller is needed.

In theory, the exthint is a hint for future allocation, I can't connect it
to the blocks which are already allocated to the file/dir.
So the only reason why we disallow that is that there might be some problems if
we allow it.  Well, can we fix the real problem(s) rather than disallowing
extsize changing?

Signed-off-by: Wengang Wang <wen.gang.wang@oracle.com>
---
 fs/xfs/xfs_ioctl.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c
index d0e2cec6210d..b34992d9932f 100644
--- a/fs/xfs/xfs_ioctl.c
+++ b/fs/xfs/xfs_ioctl.c
@@ -1221,8 +1221,7 @@ xfs_ioctl_setattr_get_trans(
 }
 
 /*
- * Validate a proposed extent size hint.  For regular files, the hint can only
- * be changed if no extents are allocated.
+ * Validate a proposed extent size hint.
  */
 static int
 xfs_ioctl_setattr_check_extsize(
@@ -1236,10 +1235,6 @@ xfs_ioctl_setattr_check_extsize(
 	if (!fa->fsx_valid)
 		return 0;
 
-	if (S_ISREG(VFS_I(ip)->i_mode) && ip->i_df.if_nextents &&
-	    XFS_FSB_TO_B(mp, ip->i_extsize) != fa->fsx_extsize)
-		return -EINVAL;
-
 	if (fa->fsx_extsize & mp->m_blockmask)
 		return -EINVAL;
 
-- 
2.39.3 (Apple Git-146)


             reply	other threads:[~2024-05-08 17:04 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-08 17:03 Wengang Wang [this message]
2024-05-11  1:56 ` [PATCH] xfs: allow changing extsize on file Dave Chinner
2024-05-13 17:17   ` Wengang Wang
2024-05-20  4:58 ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240508170343.2774-1-wen.gang.wang@oracle.com \
    --to=wen.gang.wang@oracle.com \
    --cc=david@fromorbit.com \
    --cc=linux-xfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox