> On Dec 15, 2023, at 12:20 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > 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... > Yes, thanks for the answers. I will try it out. Thanks, Wengang >
