[Top] [All Lists]

Re: [RFC PATCH 04/11] xfs: update inode allocation transaction reservati

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [RFC PATCH 04/11] xfs: update inode allocation transaction reservations for finobt
From: Brian Foster <bfoster@xxxxxxxxxx>
Date: Thu, 05 Sep 2013 12:17:23 -0400
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20130905005946.GR23571@dastard>
References: <1378232708-57156-1-git-send-email-bfoster@xxxxxxxxxx> <1378232708-57156-5-git-send-email-bfoster@xxxxxxxxxx> <20130905005946.GR23571@dastard>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8
On 09/04/2013 08:59 PM, Dave Chinner wrote:
> On Tue, Sep 03, 2013 at 02:25:01PM -0400, Brian Foster wrote:
>> Update inode allocation transaction reservations for the finobt. A
>> create via record modification requires a log reservation for the
>> additional finobt record. Any such allocation could result in an
>> finobt removal if the inode chunk has become fully allocated, thus
>> we include a reservation for a finobt btree merge as well.
>> Allocation of a new inode chunk must account for splits in the
>> finobt as well as the existing ialloc tree.
> These transaction reservation changes are only necessary for
> filesystems with free inode btrees, otherwise they just use more log
> space than is necessary.

Yeah, good point.

> Can you add helper functions for the free inode btree reservations,
> and have them return 0 when the feature is not enabled? That way the
> code stays pretty clean, is self documenting and doesn't take
> unnecessary space when the feature is not enabled....

So not new functions that duplicate the entire calculations for the
finobt enabled cases, but new functions that define the additional
requirements for the finobt on top of the existing reservation
calculations for particular operations (i.e., similar to the recent
patch to fix the inode log size, if I recall). Sounds good.


>> Also update XFS_IALLOC_SPACE_RES() to reserve data blocks for
>> finobt split/merge scenarios.
> Needs to handle the enabled/disabled case, too.
> Cheers,
> Dave.

<Prev in Thread] Current Thread [Next in Thread>