From: Jakob Oestergaard <jakob@unthought.net>
To: "Stephen C. Tweedie" <sct@redhat.com>
Cc: linux-kernel@vger.kernel.org, Andrew Morton <akpm@zip.com.au>
Subject: Re: jbd bug(s) (?)
Date: Thu, 26 Sep 2002 14:21:24 +0200 [thread overview]
Message-ID: <20020926122124.GS2442@unthought.net> (raw)
In-Reply-To: <20020925173605.A12911@redhat.com>
On Wed, Sep 25, 2002 at 05:36:05PM +0100, Stephen C. Tweedie wrote:
> Hi,
..
> > Isn't this a problem ?
>
> Nah. In fact I should just remove the loop entirely. For commit
> processing, only the header at the very, very start of a commit block
> is cared about --- that way, we get atomic commits even if the commit
> block is partially written out-of-order on disk. As long as sector
> writes within the fs block are atomic, the header remains intact.
Ok, fair enough.
The loop (which performs a number of repeated identical writes to the
*same* location) along with the comment does look pretty scary though
8)
>
> > The jbd superblocks contains an index into the journal for the first
> > transaction - but there is only *one* copy of the index, and there is no
> > reasonable way to detect if it got written correctly to disk.
> >
> > If the system loses power while updating the superblock, and only *half*
> > of this index is written correctly, we have a journal which we cannot
> > reach.
>
> Again, only the data in the first sector matters there, and we assume
> that disks write individual sectors atomically, or return IO failure
> if things get messed up.
Yep - so does Reiser. I originally believed that this was not the case
with modern disks, but I think I was corrected on that one in the Reiser
bug thread :)
...
> > Sort of removes the point of having the journal in the first place. (If
> > my above assertion is true).
>
> Actually, the number of single points of failure in a filesystem is
> huge.
[snip]
Originally it was my impression that the index was written fairly
frequently, *and* that you did not have the atomic-sector-write
guarantee.
That's why I was very worried.
> So if we detect incomplete sector writes, we can recover by forcing a
> fsck, but if you want to be able to survive actual data loss, you need
> raid.
RAID wouldn't save me in the case where the journal index is screwed due
to a partial sector write and a power loss.
But anyway, that is a moot point :)
Thank you for explaining,
(/me hopes the scary-loop dies ;)
--
................................................................
: jakob@unthought.net : And I see the elder races, :
:.........................: putrid forms of man :
: Jakob Østergaard : See him rise and claim the earth, :
: OZ9ABN : his downfall is at hand. :
:.........................:............{Konkhra}...............:
next prev parent reply other threads:[~2002-09-26 12:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-24 7:21 jbd bug(s) (?) Jakob Oestergaard
2002-09-25 16:36 ` Stephen C. Tweedie
2002-09-26 12:21 ` Jakob Oestergaard [this message]
2002-09-26 12:27 ` Stephen C. Tweedie
2002-09-26 12:56 ` Jakob Oestergaard
2002-09-26 13:44 ` Theodore Ts'o
2002-09-26 14:05 ` Christoph Hellwig
2002-09-26 14:25 ` Theodore Ts'o
2002-09-26 14:41 ` Christoph Hellwig
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=20020926122124.GS2442@unthought.net \
--to=jakob@unthought.net \
--cc=akpm@zip.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=sct@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.