[Top] [All Lists]

Re: [PATCH v5 00/18] xfs: sparse inode chunks

To: Brian Foster <bfoster@xxxxxxxxxx>
Subject: Re: [PATCH v5 00/18] xfs: sparse inode chunks
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Fri, 20 Feb 2015 10:01:50 +1100
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20150219191034.GA5750@xxxxxxxxxxxxxxx>
References: <1424369623-5656-1-git-send-email-bfoster@xxxxxxxxxx> <20150219191034.GA5750@xxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Thu, Feb 19, 2015 at 02:10:34PM -0500, Brian Foster wrote:
> On Thu, Feb 19, 2015 at 01:13:25PM -0500, Brian Foster wrote:
> > Hi all,
> > 
> > Here's v5 of sparse inode chunks. The only real change here is to
> > convert the allocmask helpers back to using the XFS bitmap helpers
> > rather than the generic bitmap code. This eliminates the need for the
> > endian-conversion hack and extra helper to export a generic bitmap to a
> > native type. The former users of the generic bitmap itself have been
> > converted to use the native 64-bit value appropriately.
> > 
> > The XFS bitmap code is actually not in userspace either so neither of
> > these implementations backport cleanly to userspace. As it is, I've not
> > included the sparse alloc/free code in my xfsprogs branch as this code
> > currently isn't needed. Nothing in userspace that I've seen requires the
> > ability to do a sparse inode allocation or free. I suspect if it is
> > needed in the future, we can more easily sync the XFS bitmap helpers to
> > userspace than the generic Linux bitmap code.
> > 
> > Thoughts, reviews, flames appreciated...
> > 
> Attached is a tarball of a set of xfsprogs patches to aid in testing
> this patchset. I'm posting as a tarball because the core patches (e.g.,
> the kernel patches) are obviously still in flux. The tarball includes
> the following:
> - general dependency backports
> - core infrastructure backports (i.e., applicable patches from this v5
>   sparse inode set)
> - xfsprogs work for sparse inode support

You should probably base it on the libxfs-3.19-update branch rather
than backport random patches into the current branch. This is what
I'm basing the current rmap-btree work I'm doing on, and having the
same libxfs structure on both sides makes it way easier to keep both
sides up to date....

Give me a couple of hours and I'll push out the latest updates to
that the branch...


Dave Chinner

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