Re: [PATCHSET v3.1 0/7] data integrity: Stabilize pages duringwriteback for various fses

[Darrick J. Wong]

On Mon, May 16, 2011 at 08:59:47PM +0200, Jan Kara wrote:
> On Mon 16-05-11 11:49:27, Darrick J. Wong wrote:
> > On Thu, May 12, 2011 at 11:42:55AM +0200, Jan Kara wrote:
> > > On Wed 11-05-11 11:19:01, Darrick J. Wong wrote:
> > > > On Tue, May 10, 2011 at 02:51:24PM +0200, Jan Kara wrote:
> > > > > On Mon 09-05-11 16:03:18, Darrick J. Wong wrote:
> > > > > > I am still chasing down what exactly is broken in ext3.  data=writeback mode
> > > > > > passes with no failures.  data=ordered, however, does not pass; my current
> > > > > > suspicion is that jbd is calling submit_bh on data buffers but doesn't call
> > > > > > page_mkclean to kick the userspace programs off the page before writing it.
> > > > >   Yes, ext3 in data=ordered mode writes pages from
> > > > > journal_commit_transaction() via submit_bh() without clearing page dirty
> > > > > bits thus page_mkclean() is not called for these pages. Frankly, do you
> > > > > really want to bother with adding support for ext2 and ext3? People can use
> > > > > ext4 as a fs driver when they want to start using blk-integrity support.
> > > > > Especially ext2 patch looks really painful and just from a quick look I can
> > > > > see code e.g. in fs/ext2/namei.c which isn't handled by your patch yet.
> > > > 
> > > > Yeah, I agree that ext2 is ugly and ext3/jbd might be more painful.  Are there
> > > > any other code that wants stable pages that's already running with ext3?  In
> > > > this months-long discussion I've heard that encryption and raid also like
> > > > stable pages during writes.  Have those users been broken this whole time, or
> > > > have they been stabilizing pages themselves?
> > >   I believe part of them has been broken (e.g. raid) and part of them do
> > > copy-out so they were OK.
> > 
> > A future step might be to undo all these homegrown copy-outs?
>   Sure but I'm not the right one to tell you where these are ;).

Yes, I've found a couple just by digging through the source tree.  But maybe
I'll get this small set upstream before writing more patches.

> > > > I suppose we can cross the "ext3 fails horribly on DIF" bridge when someone
> > > > complains about it.  Possibly we could try to steer them to btrfs.
> > >   Well, btrfs might be a bit too advantageous for production servers but
> > > ext4 would be definitely viable for them.
> > 
> > Are there any distros that are going straight from ext3 to btrfs?
>   Most distros currently offer users a choice of xfs, ext3, ext4, btrfs
> with ext4 being the default. I'm not sure if that's what you are asking
> about...

Yep.  I was primarily concerned that there might be some customer that would be
ok with deploying DIF hardware and rolling forward to ext4, but not to btrfs,
only to find that some distro refused to ship ext4.  Looks like SLES/RHEL both
do, however. :)

--D
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/