Thread (24 messages) 24 messages, 6 authors, 2011-05-18

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

From: Darrick J. Wong <hidden>
Date: 2011-05-16 19:09:20
Also in: linux-fsdevel, linux-mm, linux-scsi, lkml

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:
quoted
On Thu, May 12, 2011 at 11:42:55AM +0200, Jan Kara wrote:
quoted
On Wed 11-05-11 11:19:01, Darrick J. Wong wrote:
quoted
On Tue, May 10, 2011 at 02:51:24PM +0200, Jan Kara wrote:
quoted
On Mon 09-05-11 16:03:18, Darrick J. Wong wrote:
quoted
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.
quoted
quoted
quoted
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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help