public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
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: Tue, 2 Jun 2015 06:47:03 +1000	[thread overview]
Message-ID: <20150601204703.GI24666@dastard> (raw)
In-Reply-To: <20150601125638.GB62578@bfoster.bfoster>

On Mon, Jun 01, 2015 at 08:56:39AM -0400, Brian Foster wrote:
> 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:
> > - kernel code seems to be regression from when not using sparse
> >   inodes
> 
> What regression are you referring to?

Doh! typo there. s/from/free/

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

Can you port it to the current dev branch (libxfs-4.1-update)? That
way will be much easier for you, and me when it comes to merging..

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2015-06-01 20:47 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
2015-06-01 20:47       ` Dave Chinner [this message]
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=20150601204703.GI24666@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