xfs
[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:49:35 +1100
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20150219232024.GA8498@xxxxxxxxxxxxxx>
References: <1424369623-5656-1-git-send-email-bfoster@xxxxxxxxxx> <20150219191034.GA5750@xxxxxxxxxxxxxxx> <20150219230150.GZ12722@dastard> <20150219232024.GA8498@xxxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Thu, Feb 19, 2015 at 06:20:24PM -0500, Brian Foster wrote:
> On Fri, Feb 20, 2015 at 10:01:50AM +1100, Dave Chinner wrote:
> > 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....
> > 
> 
> I wasn't aware we had such a branch... I don't see it in my xfsprogs
> repo. Perhaps that's because my repo is still based on the oss.sgi.com
> repo?

Possibly, though I thought I pushed it there. I don't tend to look
at the oss repositories these days, and only push to them at release
time.

https://git.kernel.org/cgit/fs/xfs/xfsprogs-dev.git/log/?h=libxfs-3.19-update

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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