From: Dave Chinner <david@fromorbit.com>
To: Brian Foster <bfoster@redhat.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH v5 00/18] xfs: sparse inode chunks
Date: Fri, 20 Feb 2015 10:49:35 +1100 [thread overview]
Message-ID: <20150219234935.GC12722@dastard> (raw)
In-Reply-To: <20150219232024.GA8498@laptop.bfoster>
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@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2015-02-19 23:49 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-19 18:13 [PATCH v5 00/18] xfs: sparse inode chunks Brian Foster
2015-02-19 18:13 ` [PATCH v5 01/18] xfs: create individual inode alloc. helper Brian Foster
2015-02-19 18:13 ` [PATCH v5 02/18] xfs: update free inode record logic to support sparse inode records Brian Foster
2015-02-19 18:13 ` [PATCH v5 03/18] xfs: support min/max agbno args in block allocator Brian Foster
2015-02-19 18:13 ` [PATCH v5 04/18] xfs: add sparse inode chunk alignment superblock field Brian Foster
2015-02-19 18:13 ` [PATCH v5 05/18] xfs: use sparse chunk alignment for min. inode allocation requirement Brian Foster
2015-02-19 18:13 ` [PATCH v5 06/18] xfs: sparse inode chunks feature helpers and mount requirements Brian Foster
2015-02-19 18:13 ` [PATCH v5 07/18] xfs: add fs geometry bit for sparse inode chunks Brian Foster
2015-02-19 18:13 ` [PATCH v5 08/18] xfs: introduce inode record hole mask " Brian Foster
2015-02-19 18:13 ` [PATCH v5 09/18] xfs: use actual inode count for sparse records in bulkstat/inumbers Brian Foster
2015-02-19 18:13 ` [PATCH v5 10/18] xfs: pass inode count through ordered icreate log item Brian Foster
2015-02-19 18:13 ` [PATCH v5 11/18] xfs: handle sparse inode chunks in icreate log recovery Brian Foster
2015-02-19 18:13 ` [PATCH v5 12/18] xfs: helper to convert holemask to inode alloc. bitmap Brian Foster
2015-02-19 18:13 ` [PATCH v5 13/18] xfs: allocate sparse inode chunks on full chunk allocation failure Brian Foster
2015-02-19 18:13 ` [PATCH v5 14/18] xfs: randomly do sparse inode allocations in DEBUG mode Brian Foster
2015-02-19 18:13 ` [PATCH v5 15/18] xfs: filter out sparse regions from individual inode allocation Brian Foster
2015-02-19 18:13 ` [PATCH v5 16/18] xfs: only free allocated regions of inode chunks Brian Foster
2015-02-19 18:13 ` [PATCH v5 17/18] xfs: skip unallocated regions of inode chunks in xfs_ifree_cluster() Brian Foster
2015-02-19 18:13 ` [PATCH v5 18/18] xfs: enable sparse inode chunks for v5 superblocks Brian Foster
2015-02-19 19:10 ` [PATCH v5 00/18] xfs: sparse inode chunks Brian Foster
2015-02-19 23:01 ` Dave Chinner
2015-02-19 23:20 ` Brian Foster
2015-02-19 23:49 ` Dave Chinner [this message]
2015-06-01 0:12 ` Dave Chinner
2015-06-01 12:56 ` Brian Foster
2015-06-01 20:47 ` Dave Chinner
2015-06-01 21:21 ` Brian Foster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150219234935.GC12722@dastard \
--to=david@fromorbit.com \
--cc=bfoster@redhat.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox