Neil Brown wrote:
The other is to use a filesystem that allows the problem to be avoided
by making sure that the only blocks that can be corrupted are dead
blocks.
This could be done with a copy-on-write filesystem that knows about the
raid5 geometry, and only ever writes to a stripe when no
Guy ([EMAIL PROTECTED]) wrote on 19 November 2005 00:56:
Assume a single stripe has data for 2 different files (A and B). A disk has
failed. The file system writes a 4K chunk of data to file A. The parity
gets updated, but not the data. Or the data gets updated but not the
parity. The
Neil Brown ([EMAIL PROTECTED]) wrote on 19 November 2005 16:54:
There are two solutions to this silent corruption problem (other than
'ignore it and hope it doesn't bite' which is a fair widely used
solution, and I haven't seen any bite marks myself).
It happened to me several years ago when
On Saturday November 19, [EMAIL PROTECTED] wrote:
I've just installed a new server with a 5-disk raid5 and kernel
2.6.14.2. To check something I did a hard reset without shutdown and
on reboot the machine didn't do any automatic resync; all arrays are
shown clean.
Is this some automatic
