I am trying to investigate how freelist allocator in xfs interacts with freespace B+Tree allocator. First I prepared a patch <https://gist.github.com/22ffca35929e67c08759b057779b7566> on linux-source/fs/xfs/libxfs/xfs_alloc.c to print debugging messages (The kernel version used is linux-3.10.0-327.22.2.el7). Then, I wrote a simple utility <https://gist.github.com/992364ceca984d3f14099ec94aaacd9d> to make TONS of holes in a filesystem by calling fallocate() to punch holes in a file that is almost as large as the volume size. I created an XFS filesystem image by the following steps: 1. fallocate -l 80G /mnt/disk2/xfs 2. mkfs.xfs -f -d agcount=1 /mnt/disk2/xfs Then I created a large file by fallocate: fallocate -l 85823746048 /mnt/test/abc which left only 4 blocks available in the volume finally: /dev/loop0 20961280 20961276 4 100% /mnt/test The result of xfs_bmap against /mnt/test/abc: /mnt/test/abc: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS 0: [0..167624503]: 83000..167707503 0 (83000..167707503) 167624504 10000 After that, I used the hole-punching utility above to create holes on the files, and captured the output of kmsg. When reading the log output <https://gist.github.com/890076405e1c13c0a952a579e25e6afe> , I realised that there is no B+Tree split triggered by xfs_alloc_fix_freelist() when calling xfs_free_extent(). Isn't B+Tree split possible in by-size B+Tree even when truncating a longer freespace record to shorter one? But what I found in the log is only a few tree shrinks... And when reading the source code of freespace allocator I found that a B+Tree growth in this case is impossible at least... _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
