Some questions about the freelist allocator in XFS

[Kaho Ng]

I am trying to investigate how freelist allocator in xfs interacts
with freespace B+Tree allocator.
First I prepared a patch against
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 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, 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...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kernel-log
Type: application/octet-stream
Size: 4484601 bytes
Desc: not available
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20160707/2e64abd4/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: punch.c
Type: text/x-csrc
Size: 1003 bytes
Desc: not available
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20160707/2e64abd4/attachment-0001.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xfs_alloc.c.patch
Type: text/x-patch
Size: 4413 bytes
Desc: not available
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20160707/2e64abd4/attachment-0001.patch>