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...