[lkml]   [2002]   [May]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.5.12 severe ext3 filesystem corruption warning!
On Thu, 02 May 2002, Andrew Morton wrote:
> Alexander Viro wrote:
>> On Thu, 2 May 2002, Andrew Morton wrote:
>> > A few things..


>> I suspect that you had screwed the truncate exclusion warranties up.
>> If _any_ IO happens in the area currently manipulated by ->truncate()
>> - you are screwed and results would look pretty much like the things
>> mentioned in bug report.
> OK, thanks. That's something to go on.
> The only change which comes to mind is discard_buffer() - it's
> no longer clearing BH_Uptodate. Because for the partial page
> at the end of the mapping, buffers outside i_size were zeroed
> in truncate_partial_page(). But with (presumed) 4k blocksize,
> it can't be that.
> ext3_writepage() can hold a reference against the buffers
> after the page has come unlocked, so a try_to_free in the
> right window will fail, which will leave the page floating
> about on the page LRU, not mapped into any address_space,
> clean, not uptodate, but with uptodate buffers. Nobody
> but the VM should ever find that page, but it does make more
> sense to mark that buffer not uptodate. This would only
> happen on super-heavy SMP loads.

Oh, it's a laptop, so SMP is right out of the picture. ;)

Many of my favorite shamans are rock stars. They probably don't even know
they're shamans but they know how to get to ecstasy and back, and how to take
others with them. They may not have a license, but they know how how to drive.
-- Gabrielle Roth, _Maps to Ecstasy_
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:25    [W:0.038 / U:1.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site