On Fri, Dec 15, 2023 at 05:07:36PM +0000, Wengang Wang wrote: > > On Dec 14, 2023, at 7:15 PM, Dave Chinner <david@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx
