From: Daniel Pittman <daniel@rimspace.net>
To: Andrew Morton <akpm@zip.com.au>
Cc: Alexander Viro <viro@math.psu.edu>, linux-kernel@vger.kernel.org
Subject: Re: 2.5.12 severe ext3 filesystem corruption warning!
Date: Fri, 03 May 2002 08:39:18 +1000 [thread overview]
Message-ID: <87u1pq18fd.fsf@enki.rimspace.net> (raw)
In-Reply-To: <3CD191C5.AC09B1F4@zip.com.au> <Pine.GSO.4.21.0205021530010.16530-100000@weyl.math.psu.edu> <3CD1A2E2.A240823C@zip.com.au>
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. ;)
Daniel
--
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_
next prev parent reply other threads:[~2002-05-02 22:39 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-02 13:01 2.5.12 severe ext3 filesystem corruption warning! Daniel Pittman
2002-05-02 19:21 ` Andrew Morton
2002-05-02 19:34 ` Alexander Viro
2002-05-02 20:34 ` Andrew Morton
2002-05-02 22:39 ` Daniel Pittman [this message]
2002-05-02 22:37 ` Daniel Pittman
2002-05-02 23:00 ` Andrew Morton
2002-05-03 0:02 ` Daniel Pittman
-- strict thread matches above, loose matches on Subject: below --
2002-05-02 21:40 Andries.Brouwer
2002-05-02 20:50 ` Martin Dalecki
2002-05-02 21:58 ` Andrew Morton
2002-05-02 22:57 ` Daniel Pittman
2002-05-04 5:26 ` Milton Miller
2002-05-04 5:46 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87u1pq18fd.fsf@enki.rimspace.net \
--to=daniel@rimspace.net \
--cc=akpm@zip.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@math.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox