Hmm, wouldn't xfs_alloc_ag_vextent_size() first remove the free extent record, and insert a new extent record into the freespace by-size btree if the found free extent record is longer than args->maxlen? On Fri, Jul 8, 2016 at 6:28 AM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > 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). > ...... >> 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... > > args->isfl doesn't mean what you think it means. > > args->isfl is only set when moving blocks from the freespace btree > to the AGFL, which only occurs when a previous operation allocated a > new freespace btree block and depleted the current freelist. i.e. > "AG Free List" != "AG freespace btree" - they are different > structures on disk... > > And when you consider that a freelist refill can only remove records > from the the freespace btree, it's should be clear that a btree > split won't occur during a freelist refill... > > Cheers, > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
