Re: [PATCH 0/9] xfs file non-exclusive online defragment

[Dave Chinner <david@fromorbit.com>]

On Fri, Dec 15, 2023 at 05:07:36PM +0000, Wengang Wang wrote:
> > On Dec 14, 2023, at 7:15 PM, Dave Chinner <david@fromorbit.com> wrote:
> > If we were to implement this as, say, and xfs_spaceman operation
> > then all the user controlled policy bits (like inter chunk delays,
> > chunk sizes, etc) then just becomes command line parameters for the
> > defrag command...
> 
> 
> Ha, the idea from user space is very interesting!
> So far I have the following thoughts:
> 1). If the FICLONERANGE/FALLOC_FL_UNSHARE_RANGE/FALLOC_FL_PUNCH works on a FS without reflink
>      enabled.

Personally, I don't care if reflink is not enabled. It's the default
for new filesystems, and it's cost free for anyone who is not
using reflink so there is no reason for anyone to turn it off.

What I'm saying is "don't compromise the design of the functionality
required just because someone might choose to disable that
functionality".

> 2). What if there is a big hole in the file to be defragmented? Will it cause block allocation and writing blocks with
>     zeroes.

Unshare skips holes.

> 3). In case a big range of the file is good (not much fragmented), the ‘defrag’ on that range is not necessary.

xfs_fsr already deals with this - it uses XFS_IOC_GETBMAPX to scan
the extent list to determine what to defrag, to replicate unwritten
regions and to skip holes. Having to scan the extent list is kinda
expected for a defrag utility

> 4). The use space defrag can’t use a try-lock mode to make IO requests have priorities. I am not sure if this is very important.

As long as the individual operations aren't holding locks for a long
time, I doubt it matters. And you can use ionice to make sure the IO
being issued has background priority in the block scheduler...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com