[OpenIndiana-discuss] System disk corruption

[Robin Axelsson]

On 2012-02-20 16:57, Jan Owoc wrote:
> On Mon, Feb 20, 2012 at 7:38 AM, Robin Axelsson
> <gu99roax at student.chalmers.se>  wrote:
>> It is evident that ZFS is not very good to use without disk redundancy.
> In your case, you would have silent data corruption on-disk. This
> corrupted data would get passed to programs, that would try to work
> with what they have. In some cases, you might be lucky - in others,
> your system would randomly crash.
>
> If you are frustrated about being informed about disk errors, and
> would prefer the system to not check, it is possible to set
> "checksum=off". This is not recommended.
I'm not frustrated about it. I have acknowledged the error and all I 
want(ed) to do is to let zfs loose the grip on it so that I can fix it 
by other means. Temporarily disabling the checksum flag/property of the 
dataset didn't make the corrupt part of the file "readable" again; cp 
still halted with an I/O error.

In this case it was a hard drive image of a virtual machine that was 
corrupted. I trust the operating system of that VM to be able to restore 
system integrity enough to ensure stability, there are no vital files in 
it that cannot be replaced. If I can see the data surrounding the 
corrupt datablock with a hex editor I may even figure out which data 
file that is affected and just replace it manually.

>
> On Mon, Feb 20, 2012 at 8:05 AM, Gregory Youngblood
> <gregory at youngblood.me>  wrote:
>>> It would be great if there were some kind of software that could be set up to generate .par2 files (with x% data redundancy) on-the-fly to protect files on hard drives without disk redundancy (RAID=0).
>> What about telling zfs to maintain more than one copy? Not sure how well data is spread out if there is only one drive though. Anyone know?
> Yes, there is an option copies=2 (or 3) to have each data block have a
> "ditto block" somewhere else on the filesystem. You need twice (or
> three times) the capacity to do this. Both copies are still physically
> on the same drive, so while this protects against random data
> corruption or a few bad sectors, it does not protect against the
> single drive failing.
>
> Gregory is talking about generating something like "ECC" for each
> block. Such an algorithm, for example, could be set to use an
> additional 10% of information stored with the checksum to attempt
> recovery of the target block. I'm not aware of any such option at the
> present, but adding it would require a new zpool version.
>
>
> Jan
>
> _______________________________________________
> OpenIndiana-discuss mailing list
> OpenIndiana-discuss at openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss
>
>