public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: johnrobertbanks@fastmail.fm
To: "Dale Amon" <amon@vnl.com>
Cc: "Jan Harkes" <jaharkes@cs.cmu.edu>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: Reiser4. BEST FILESYSTEM EVER.
Date: Sat, 07 Apr 2007 08:28:04 -0700	[thread overview]
Message-ID: <1175959684.29481.1183471808@webmail.messagingengine.com> (raw)
In-Reply-To: <20070407125914.GA31074@vnl.com>

On Sat, 7 Apr 2007 13:59:14 +0100, "Dale Amon" <amon@vnl.com> said:
> Jan does have a point about bad blocks. A couple years ago
> I had a relatively new disk start to go bad on random blocks.
> I detected it fairly quickly but did have some data loss.
> 
> All the compressed archives which were hit were near
> total losses; most other files were at least partially
> recoverable.

As you know, there is not substitute for backups. What if the disk had
totally crashed and scratched GBs of your data.

And did you ever trust those (non-compressed) executables that you saved
after recovering them from corruption?

Of course not. No one would. The fact that they were not compressed did
not save them.

You are really arguing for backups, not for one filesystem or another.

Besides, Jan claimed that corruption due to bad blocks propagates to
MULTIPLE files because of the compression in the file system. You are
arguing something different.

> It is not a matter of your operating system writing
> to bad blocks. It is a matter of what happens when the
> blocks on which your data sit go bad underneath you.
>
> This issue has also been discussed by people working
> with revision control system. If you are archiving
> data, how do you know you if your data is still good
> unless you actually need it? If you do not know it
> is bad, you may well get rid of good copies thinking
> you do not need the extras... it does happen.
> 
> I would be quite hesitant to go with on disk compression
> unless damage was limited to only the bad bits or blocks
> and did not propagate through the rest of the file.

You don't really mean that. Most backup uses compression (which
propagates errors through the rest of the file).

> Perhaps if everyone used hardware RAID and the RAID
> automatically detected a difference due to trashed
> data on one disk and flagged the admin with a warning...
> 
> BTW: I'm a CMU Alum, so who are you working with John?

I retired quite young.
-- 
  
  johnrobertbanks@fastmail.fm

-- 
http://www.fastmail.fm - Send your email first class


  reply	other threads:[~2007-04-07 15:28 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-07 12:59 Reiser4. BEST FILESYSTEM EVER Dale Amon
2007-04-07 15:28 ` johnrobertbanks [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-04-05 22:42 REISER4: fix for reiser4_write_extent Ignatich
2007-04-06  0:05 ` Reiser4. BEST FILESYSTEM EVER? I need help johnrobertbanks
2007-04-06  0:23   ` H. Peter Anvin
2007-04-06  0:34     ` johnrobertbanks
2007-04-06  0:39       ` H. Peter Anvin
2007-04-06  1:34         ` Reiser4. BEST FILESYSTEM EVER johnrobertbanks
2007-04-06  3:12           ` Valdis.Kletnieks
2007-04-06  4:07           ` H. Peter Anvin
2007-04-06  4:32             ` johnrobertbanks
     [not found]               ` <20070406152119.GC4228@delft.aura.cs.cmu.edu>
2007-04-07  2:47                 ` johnrobertbanks
2007-04-07  3:30                   ` Jan Harkes
2007-04-07  5:58                     ` johnrobertbanks
2007-04-07  7:15                       ` Willy Tarreau
2007-04-07 13:47                         ` johnrobertbanks
2007-04-07 14:11                       ` Krzysztof Halasa
2007-04-07 15:07                         ` johnrobertbanks
2007-04-07 16:05                           ` Pekka Enberg
2007-04-07 17:10                         ` Valdis.Kletnieks
2007-04-08 16:31                           ` Adrian Bunk
2007-04-07 17:21                         ` Valdis.Kletnieks
2007-04-08  0:41                           ` Krzysztof Halasa
2007-04-07 17:39                   ` Valdis.Kletnieks
2007-04-07 19:17               ` Lennart Sorensen
2007-04-08  0:44                 ` johnrobertbanks
2007-04-08  1:27                   ` Lennart Sorensen
2007-04-08  2:56                   ` Theodore Tso
2007-04-08  4:13                     ` johnrobertbanks
2007-04-08 12:48                       ` Jose Celestino
2007-04-08 13:21                         ` johnrobertbanks
2007-04-08 14:14                           ` Willy Tarreau
2007-04-08 17:03                       ` Theodore Tso
2007-04-08 18:18                         ` Jeff Mahoney
2007-04-08  4:32                   ` Christer Weinigel
2007-04-09 18:35                     ` Nate Diller

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=1175959684.29481.1183471808@webmail.messagingengine.com \
    --to=johnrobertbanks@fastmail.fm \
    --cc=amon@vnl.com \
    --cc=jaharkes@cs.cmu.edu \
    --cc=linux-fsdevel@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox