> On Jul 15, 2024, at 5:29 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > On Thu, Jul 11, 2024 at 11:36:28PM +0000, Wengang Wang wrote: >> >> >>> On Jul 9, 2024, at 1:21 PM, Darrick J. Wong <djwong@xxxxxxxxxx> wrote: >>> >>> On Tue, Jul 09, 2024 at 12:10:28PM -0700, Wengang Wang wrote: >>>> According to current kernel implemenation, non-zero extsize might affect >>>> the result of defragmentation. >>>> Just print a warning on that if non-zero extsize is set on file. >>> >>> I'm not sure what's the point of warning vaguely about extent size >>> hints? I'd have thought that would help reduce the number of extents; >>> is that not the case? >> >> Not exactly. >> >> Same 1G file with about 54K extents, >> >> The one with 16K extsize, after defrag, it’s extents drops to 13K. >> And the one with 0 extsize, after defrag, it’s extents dropped to 22. > > extsize should not affect file contiguity like this at all. Are you > measuring fragmentation correctly? i.e. a contiguous region from an > larger extsize allocation that results in a bmap/fiemap output of > three extents in a unwritten/written/unwritten is not fragmentation. I was using FS_IOC_FSGETXATTR to get the number of extents (fsx.fsx_nextents). So if kernel doesn’t lie, I got it correctly. There was no unwritten extents in the files to defrag. (As I mentioned somewhere else), though extsize is mainly used to align the number of blocks, it breaks delayed-allocations. In the unshare path, there are N allocations performed for the N extents respectively in the segment to be defragmented. Thanks, Wengang
