lkml.org 
[lkml]   [2006]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.19 file content corruption on ext3
On Tue, 19 Dec 2006 16:03:49 -0800 (PST)
Linus Torvalds <torvalds@osdl.org> wrote:

>
>
> On Wed, 20 Dec 2006, Peter Zijlstra wrote:
>
> > On Tue, 2006-12-19 at 14:58 -0800, Andrew Morton wrote:
> >
> > > Well... we'd need to see (corruption && this-not-triggering) to be sure.
> > >
> > > Peter, have you been able to trigger the corruption?
> >
> > Yes; however the mail I send describing that seems to be lost in space.
>
> Btw, can somebody actually explain the mess that is ext3 "dirtying".
>
> Ext3 does NOT use __set_page_dirty_buffers. It does
>
> static int ext3_journalled_set_page_dirty(struct page *page)
> {
> SetPageChecked(page);
> return __set_page_dirty_nobuffers(page);
> }
>
> and uses that "Checked" bit as a "whole page is dirty" bit (which it tests
> in "writepage()".

This is purely for data=journal, which is rarely used.

In journalled-data mode, write(), write-fault, etc are not allowed to dirty
the pages and buffers, because the data has to be written to the journal
first. After the data has been written to the journal we only then mark
buffers (and hence pages) dirty as far as the VFS is concerned. For
checkpointing the data back to its real place on the disk.


For MAP_SHARED pages ext3 cheats madly and doesn't journal the data at all.
In all journalling modes, MAP_SHARED data follows the regular ext2-style
handling. Which is a bit of a wart.

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

\
 
 \ /
  Last update: 2006-12-20 01:21    [W:0.283 / U:2.552 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site