On Sat, 7 Apr 2007 13:59:14 +0100, "Dale Amon" <[email protected]> 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.
--
[email protected]
--
http://www.fastmail.fm - Send your email first class
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]