Re: [QUESTION] about the freelist allocator in XFS

[Brian Foster <bfoster@redhat.com>]

On Thu, Jul 07, 2016 at 07:01:35PM +0800, Kaho Ng wrote:
> 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...
> 

I'd suggest to use a combination of xfs_db and tracepoints/xfsstats to
identify what's happening in your test sequence. E.g., unmount and use
xfs_db to identify the state of the free space btree(s) before and after
various points of your test. See [1] for examples of how to use xfs_db
to explore on-disk data structures. See 'man trace-cmd' to work with
tracepoints and /proc/fs/xfs/stats (and /proc/sys/fs/xfs/stats_clear) to
view runtime statistics (which I believe already includes the number of
btree splits).

Brian

[1] http://xfs.org/docs/xfsdocs-xml-dev/XFS_Filesystem_Structure//tmp/en-US/html/index.html

> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs