xfs
[Top] [All Lists]

Re: [PATCH 01/11] xfs: disentagle EFI release from the extent count

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH 01/11] xfs: disentagle EFI release from the extent count
From: Brian Foster <bfoster@xxxxxxxxxx>
Date: Wed, 12 Aug 2015 08:47:59 -0400
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20150812071518.GA14237@xxxxxxxxxxxxx>
References: <1438883072-28706-1-git-send-email-bfoster@xxxxxxxxxx> <1438883072-28706-2-git-send-email-bfoster@xxxxxxxxxx> <20150809073641.GA3163@xxxxxxxxxxxxx> <20150810123726.GA18933@xxxxxxxxxxxxxxx> <20150812071518.GA14237@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.23 (2014-03-12)
On Wed, Aug 12, 2015 at 12:15:18AM -0700, Christoph Hellwig wrote:
> On Mon, Aug 10, 2015 at 08:37:27AM -0400, Brian Foster wrote:
> > > As a follow on we should be able to remove atomic_inc_return and
> > > replace it with a local iterator in xfs_bmap_finish().
> > > 
> > 
> > I'm not sure what you mean here...
> 
> efi_next_extent is not only used is to find a 'slot' for the extent
> in xfs_trans_log_efi_extent.  For that we don't need an atomic_t
> in the EFI, but can have a local variable in xfs_bmap_finish.

Ok, I see. efi_next_extent isn't used for much at this point. We could
kill it entirely, we'd just have to add an index parameter to the EFI
logging function (or change up the params). We do still have asserts in
the logging and item format handlers that help ensure a properly
constructed EFI, so there is some use I suppose. I'm not sure it needed
to be atomic though, even prior to the changes in this series...

Brian

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