From: Jakob Oestergaard <jakob@unthought.net>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Disk (block) write strangeness
Date: Mon, 5 Aug 2002 21:07:06 +0200 [thread overview]
Message-ID: <20020805190706.GD2671@unthought.net> (raw)
In-Reply-To: <1028578632.18156.71.camel@irongate.swansea.linux.org.uk>
On Mon, Aug 05, 2002 at 09:17:12PM +0100, Alan Cox wrote:
> On Mon, 2002-08-05 at 19:49, Jakob Oestergaard wrote:
> > *) Either the disk writes backwards (no I don't believe that)
> > *) Or the kernel is writing 256 B blocks (AFAIK it can't)
> > *) The disk has some internal magic that cause a power-loss during
> > a full block write to leave the first half of the block intact with
> > old data, and update the second half of a block correctly with new
> > data. (And I don't believe that either).
>
> You forgot to add
>
> *) or the disk internal logic bears no resemblance to the antiquated API
> it fakes for the convenience of interface hardware and software
Fair enough - that seems like a reasonable explanation.
On a side note - what guarantees does one have ? Any pointers to papers
or other material about this ?
For example, when updating a 3 to a 4 on the disk, could I end up with a
7 ? (having 00000011 on platter, starting write of 00000100, but
after having written the one high power fails and I now have 00000111).
The above example is simple - I doubt that it would happen - but how
much can and cannot happen ? I bet the Phase Tree (Tux2) people must
have thought about this at some point... I haven't had much luck with
Google on this one...
>
> Linux also won't neccessarily do write outs in order.
But in this case, I wonder why ?
It's one huge sequential write, from the beginning of a device and 50 MB
onwards. The write is submitted in one single write() every single
time. Why start going semi-backwards and chopping things up ?
I'm *very* certain that Linux does this non-sequentially, because the
disk might be causing the half-block oddity which really surprised me,
but the disk is not caching 20 MB of data internally, for sure.
Is this an elevator deficiency in 2.4.18, or am I just moaning for no
reason at all ? ;)
Thanks for the quick reply !
Cheers,
--
................................................................
: 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-08-05 19:03 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-05 18:49 Disk (block) write strangeness Jakob Oestergaard
2002-08-05 20:17 ` Alan Cox
2002-08-05 19:07 ` Jakob Oestergaard [this message]
2002-08-06 14:44 ` Kasper Dupont
2002-08-07 8:14 ` Helge Hafting
2002-08-07 11:43 ` Itai Nahshon
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=20020805190706.GD2671@unthought.net \
--to=jakob@unthought.net \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
/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.