From: Daniel Phillips <phillips@bonn-fries.net>
To: "Albert D. Cahalan" <acahalan@cs.uml.edu>,
tuxx@aon.at (Alexander Griesser)
Cc: acahalan@cs.uml.edu (Albert D. Cahalan),
phillips@bonn-fries.net (Daniel Phillips),
cw@f00f.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 64 bit scsi read/write
Date: Mon, 23 Jul 2001 16:41:24 +0200 [thread overview]
Message-ID: <01072316412405.00315@starship> (raw)
In-Reply-To: <200107220352.f6M3q8b159289@saturn.cs.uml.edu>
In-Reply-To: <200107220352.f6M3q8b159289@saturn.cs.uml.edu>
On Sunday 22 July 2001 05:52, Albert D. Cahalan wrote:
> Alexander Griesser writes:
> > On Sun, Jul 15, 2001 at 09:08:41PM -0400, you wrote:
> >> In a tree-structured filesystem, checksums on everything would
> >> only cost you space similar to the number of pointers you have.
> >> Whenever a non-leaf node points to a child, it can hold a checksum
> >> for that child as well. This gives a very reliable way to spot
> >> filesystem errors, including corrupt data blocks.
> >
> > Hmm, maybe this is crap, but: If the checksum-calculation for one
> > node fails, wouldn't that mean, that the data in this node, is not
> > to be trusted? therefore also the checksum of this node could be
> > corrupted and so the node, 2 hops away, can't be validated with
> > 100% certitude...
>
> If I understand you right ("one"? "this"?), yes and we want that.
>
> Node 1 has children 2, 3, and 4.
> Node 3 has children 5, 6, and 7.
> Node 6 has children 8, 9, and 10. (children might be data blocks)
>
> To have a child is to have a checksum+pointer pair.
>
> If node 3 contains a corrupt pointer to node 6, then it is unlikely
> that the checksum will match. So node 6 is bad, along 8, 9, and 10.
> (actually we might not be able to know that 8, 9, and 10 exist)
> This result is wonderful, since it prevents interpreting random
> disk blocks as useful data.
>
> If node 3 contains a corrupt checksum for node 6, same thing. Damn.
> This case should be rare, since why for node 1 have a checksum
> that is OK for node 3 if node 3 has corruption?
>
> If node 6 itself is corrupt, same thing. Good, we are stopped from
> using bad data.
I agree that your suggestion will work and that doubling the size of
the metadata isn't an enormous cost, especially if you'd already
compressed it using extents. On the other hand, sometimes I just feel
like trusting the hardware a little. Both atomic-commit and
journalling strategies take care of normal failure modes, and the disk
hardware is supposed to flag other failures by ecc'ing each sector on
disk.
--
Daniel
next prev parent reply other threads:[~2001-07-23 14:37 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-07-01 4:53 [RFC][PATCH] first cut 64 bit block support Ben LaHaise
2001-07-03 4:53 ` Ragnar Kjørstad
2001-07-04 2:19 ` [PATCH] 64 bit scsi read/write Ben LaHaise
2001-07-04 7:11 ` Alan Cox
2001-07-05 6:34 ` Ragnar Kjørstad
2001-07-05 7:35 ` Ben LaHaise
2001-07-13 18:20 ` Albert D. Cahalan
2001-07-13 20:41 ` Andreas Dilger
2001-07-13 21:07 ` Chris Wedgwood
2001-07-13 22:04 ` Andreas Dilger
2001-07-14 0:49 ` Jonathan Lundell
2001-07-14 12:27 ` Paul Jakma
2001-07-14 14:48 ` Chris Wedgwood
2001-07-14 15:42 ` Paul Jakma
2001-07-14 17:18 ` Chris Wedgwood
2001-07-20 17:03 ` Stephen C. Tweedie
2001-07-16 18:53 ` Andreas Dilger
2001-07-16 19:13 ` Ragnar Kjørstad
2001-07-13 21:14 ` Alan Cox
2001-07-14 3:23 ` Andrew Morton
2001-07-14 8:45 ` Alan Cox
2001-07-14 14:50 ` Chris Wedgwood
2001-07-14 15:41 ` Jonathan Lundell
2001-07-14 17:00 ` Chris Wedgwood
2001-07-14 20:11 ` Daniel Phillips
2001-07-15 1:21 ` Andrew Morton
2001-07-15 1:53 ` Daniel Phillips
2001-07-15 3:36 ` Chris Wedgwood
2001-07-15 6:05 ` John Alvord
2001-07-15 6:07 ` Chris Wedgwood
2001-07-15 13:16 ` Ken Hirsch
2001-07-15 14:50 ` Chris Wedgwood
2001-07-15 22:14 ` Daniel Phillips
2001-07-17 0:31 ` Juan Quintela
2001-07-15 13:44 ` Daniel Phillips
2001-07-15 14:39 ` Chris Wedgwood
2001-07-15 15:06 ` Jonathan Lundell
2001-07-15 15:22 ` Chris Wedgwood
2001-07-15 17:44 ` Jonathan Lundell
2001-07-15 17:47 ` Justin T. Gibbs
2001-07-15 23:14 ` Rod Van Meter
2001-07-16 0:37 ` Jonathan Lundell
2001-07-16 15:11 ` Rod Van Meter
2001-07-16 8:56 ` Chris Wedgwood
2001-07-16 13:19 ` Daniel Phillips
2001-07-15 15:32 ` Alan Cox
2001-07-15 15:33 ` Chris Wedgwood
2001-07-15 16:24 ` Chris Wedgwood
2001-07-16 1:08 ` Albert D. Cahalan
2001-07-16 8:49 ` Chris Wedgwood
2001-07-21 19:18 ` Alexander Griesser
2001-07-22 3:52 ` Albert D. Cahalan
2001-07-23 14:41 ` Daniel Phillips [this message]
2001-07-24 4:29 ` Albert D. Cahalan
2001-07-24 11:45 ` Daniel Phillips
2001-07-14 17:33 ` Jonathan Lundell
2001-07-15 4:02 ` Chris Wedgwood
2001-07-15 5:46 ` Jonathan Lundell
2001-07-15 17:10 ` Chris Wedgwood
2001-07-15 17:39 ` Jonathan Lundell
2001-07-26 2:18 ` Ragnar Kjørstad
2001-07-26 16:24 ` Andreas Dilger
2001-08-10 19:42 ` Ben LaHaise
2001-08-10 19:51 ` Ragnar Kjørstad
2001-08-10 20:02 ` Ben LaHaise
2001-08-11 0:18 ` Steve Lord
2001-08-11 21:44 ` Matti Aarnio
2001-07-04 10:16 ` [RFC][PATCH] first cut 64 bit block support Chris Wedgwood
2001-07-04 16:59 ` Ben LaHaise
-- strict thread matches above, loose matches on Subject: below --
2001-07-14 15:08 [PATCH] 64 bit scsi read/write Ed Tomlinson
2001-07-19 7:35 [PATCH] 64 bit SCSI read/write Andre Hedrick
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=01072316412405.00315@starship \
--to=phillips@bonn-fries.net \
--cc=acahalan@cs.uml.edu \
--cc=cw@f00f.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tuxx@aon.at \
/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