From: Brian Foster <bfoster@redhat.com>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH v5 00/18] xfs: sparse inode chunks
Date: Mon, 1 Jun 2015 08:56:39 -0400 [thread overview]
Message-ID: <20150601125638.GB62578@bfoster.bfoster> (raw)
In-Reply-To: <20150601001230.GG24666@dastard>
On Mon, Jun 01, 2015 at 10:12:30AM +1000, 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
> >
> > The latter bits include support for mkfs, xfs_info, xfs_db and
> > xfs_repair, the fundamentals of all of which should work. Use the '-i
> > spalign' mkfs option to format a sparse inode enabled fs. E.g.:
> >
> > mkfs.xfs -m crc=1,finobt=1 -i spalign <dev>
> >
> > Note that metadump is not yet supported. Failures from the associated
> > xfstests, etc. are expected. I'm not aware of anything else that is
> > missing support or otherwise broken, so any feedback along those lines
> > is appreciated.
>
> Notes:
>
> - mkfs output doesn't indicate that sparse inodes are configured.
> - mkfs cli option of "-i sparse=[0|1]" makes more sense than
> "spalign"
> - "SPARSE_INODES" missing from xfs_db version output
Ok...
> - kernel code seems to be regression from when not using sparse
> inodes
What regression are you referring to?
> - inode allocation speed does not seem to be impacted by sparse
> inode allocation - running my fsmark tests on a debug kernel show
> no performance differential, even though sparse inode chunks
> should be created in that case.
> - it smoke tests through xfstests ok
>
I haven't really run into much for issues so far save for a problem
discovered with the DEBUG mode code from my recent large block size
testing. I have a patch for that lying around I need to post...
> I haven't really looked through the userspace code in any detail,
> so I can't really comment on that side of things yet. The kernel
> code looks good, there doesn't appear to be any regressions and the
> new functionailty works so far. Hence I think I'm going to merge
> the kernel code in the 4.2 cycle, and we can work on getting
> userspace into the current dev tree for people to test and use the
> new code....
>
Sounds good, thanks. The userspace bits have only been posted for
testing purposes to this point to avoid the churn from active review of
the core code. Since that is now merged, I'll get the latest mechanism
ported over to userspace, incorporate some of the fixes noted above and
get something posted hopefully soon.
Brian
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2015-06-01 12:56 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
2015-06-01 0:12 ` Dave Chinner
2015-06-01 12:56 ` Brian Foster [this message]
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=20150601125638.GB62578@bfoster.bfoster \
--to=bfoster@redhat.com \
--cc=david@fromorbit.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