On Wed, Aug 26, 2020 at 07:40:57AM +0000, bugzilla-daemon@xxxxxxxxxxxxxxxxxxx wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=209039 > > Bug ID: 209039 > Summary: xfs_fsr skips most of the files as no improvement will > be made > Product: File System > Version: 2.5 > Kernel Version: 4.19.107-Unraid > Hardware: All > OS: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: XFS > Assignee: filesystem_xfs@xxxxxxxxxxxxxxxxxxxxxx > Reporter: marc@xxxxxxx > Regression: No > > I checked the fragmentation factor of disk1 as follows: > > xfs_db -c frag -r /dev/md1 > actual 1718, ideal 674, fragmentation factor 60.77% > Note, this number is largely meaningless. > Files on this filesystem average 2.55 extents per file > Without knowing the details of your fs, it sounds like it's not very fragmented from the cursory numbers. > I tried to defrag disk1: > > xfs_fsr /dev/md1 -v -d > /mnt/disk1 start inode=0 > ino=133 > ino=133 extents=4 can_save=3 tmp=/mnt/disk1/.fsr/ag0/tmp23917 > DEBUG: fsize=30364684107 blsz_dio=16773120 d_min=512 d_max=2147483136 > pgsz=4096 > Temporary file has 4 extents (4 in original) > No improvement will be made (skipping): ino=133 > ino=135 > ino=135 extents=4 can_save=3 tmp=/mnt/disk1/.fsr/ag1/tmp23917 > orig forkoff 288, temp forkoff 0 > orig forkoff 288, temp forkoff 296 > orig forkoff 288, temp forkoff 296 > orig forkoff 288, temp forkoff 296 > orig forkoff 288, temp forkoff 296 > orig forkoff 288, temp forkoff 296 > orig forkoff 288, temp forkoff 296 > orig forkoff 288, temp forkoff 288 > set temp attr > DEBUG: fsize=28400884827 blsz_dio=16773120 d_min=512 d_max=2147483136 > pgsz=4096 > Temporary file has 4 extents (4 in original) > No improvement will be made (skipping): ino=135 > ino=138 > ... > > This means the file would still consist of 4 parts across the hdd platter after > defragmentation and because of that it's skipped. But why isn't it able to > merge the parts of this and hundreds of other files? > Note that fsr is not guaranteed to do anything. It simply attempts to reallocate a file and if the new file has better contiguity than the original, the old is swapped out for the new. The effectiveness depends on how fragmented the original file is, how much contiguous free space is available to create the new one, etc. It's usually not worth playing with fsr unless you observe some measurable performance impact of fragmentation (as opposed to just reading the fragmentation numbers, which can be misleading). Is that the case here? > More details about inode 133: > > xfs_db -r /dev/md1 -c "inode 133" -c "bmap -d" > data offset 0 startblock 1314074773 (4/240332949) count 2097151 flag 0 > data offset 2097151 startblock 1316171924 (4/242430100) count 2097151 flag > 0 > data offset 4194302 startblock 1318269075 (4/244527251) count 2097151 flag > 0 > data offset 6291453 startblock 1320366226 (4/246624402) count 1121800 flag > 0 In this case, it looks like you already have maximum sized (~8GB) extents for the first three. The extent map for this file is as efficient as it can possibly be on XFS. Brian > > -- > You are receiving this mail because: > You are watching the assignee of the bug. >
