xfs
[Top] [All Lists]

Re: [PATCH 00/11] xfs: fixes for 3.10-rc3

To: Ben Myers <bpm@xxxxxxx>
Subject: Re: [PATCH 00/11] xfs: fixes for 3.10-rc3
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 22 May 2013 07:27:19 +1000
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20130521205249.GL20028@xxxxxxx>
References: <1369123330-9579-1-git-send-email-david@xxxxxxxxxxxxx> <20130521162647.GD19505@xxxxxxx> <20130521202445.GO24543@dastard> <20130521205249.GL20028@xxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Tue, May 21, 2013 at 03:52:49PM -0500, Ben Myers wrote:
> Hey,
> 
> On Wed, May 22, 2013 at 06:24:45AM +1000, Dave Chinner wrote:
> > On Tue, May 21, 2013 at 11:26:47AM -0500, Ben Myers wrote:
> > > Hi Dave,
> > > 
> > > On Tue, May 21, 2013 at 06:01:59PM +1000, Dave Chinner wrote:
> > > > This is my current kernel bug fix patch series. I've updated it
> > > > against a current xfsdev tree, and contains all the fixes mentioned
> > > > in the "fixes for 3.10-rc2 (updated)" thread. The first 7 patches
> > > > are patches from that series. The last 4 are new patches.
> > > >
> > > > The first new patch stops CRC enabled filesystems from spamming the
> > > > log. It currently emits an "Experimental" warning ever time the
> > > > superblock is written, which is typically every 30s.
> > > >
> > > > The second path ("rework remote attr CRCs") is the changes I
> > > > mentioned in the "fixes for 3.10-rc2 (updated)" thread. The code is
> > > > far more robust as a result of these changes, and I think we really
> > > > need to change the format as done in this patch. Once we have
> > > > decided on the way forward, I'll port this to userspace.
> > > > 
> > > > The third patch fixes a remote symlink problem - I didn't hit this
> > > > until I'd redone the remote attr CRCs and the 1k block size
> > > > filesystem testing made it passed the attribute tests it was failing
> > > > on.
> > > > 
> > > > Finally, the last patch is another on-disk format change - one that
> > > > removes the 25 entry limit on ACLs. It doesn't invalidate anything
> > > > that is already on disk, just allows ACLs on v5 superblock
> > > > filesystems to store more than 25 ACLs in an xattr. In fact, it
> > > > allows (65536 - 4) / 12 = 5461 entries to be stored in a single
> > > > ACL, so I don't see anyone running out on v5 superblocks....
> > > > 
> > > > Thoughts, comments?
> > > 
> > > I'll look into these but I am concerned that we're starting to get into 
> > > 3.11
> > > territory.
> > 
> > The moment we release the first kernel with the format in it, we
> > need to use feature bits for on-disk format changes, experimental
> > tag or not. Hence IMO this needs to be fixed before an initial
> > release.
> 
> There's plenty of bits to go around.  ;)

Sure, but it's unnecessary complexity.

> > It's not a huge change from a code perspective, and it's a lot more
> > reliable in my testing....
> 
> I'm just a bit leery of a redesign at this late juncture.  We always seem to
> get into trouble at the last minute...  Another option is to revert just the
> xattr crc support and slap it back in once it has stablized after the release,
> but we need to flip a bit for that too...  Anyway, I need to look your 
> proposed
> code to see what's what.
> 
> Seems like xattrs might be one area where we could use some work in xfstests?

Not really - it's getting the xfstests xattr tests to pass that have
lead to this.

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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