zfs checksums on non-raidz

[Peter Maloney]

ps. Try what I showed you in a vm rather than a real system, to keep
your data safe.

Am 08.02.2012 20:29, schrieb Peter Maloney:
> Am 08.02.2012 19:47, schrieb Tom Vier:
>> In mirror and single dev zpools, are data and metadata still checksummed, or
>> only when using raidz? 
>>
>> I've only been able to determine so far that the uberblocks at the zpool level
>> are always checksummed (according to Sun's on-disk format pdf).
>>
> Everything, even a single disk, is checksummed.
>
> Test it with:
>
>
> zpool create testpool gpt/testslice
> cp /some/big/test/file /testpool/
>
> # next command is dangerous because it means you can now directly write
> to disks and damage the data
> sysctl kern.geom.debugflags=0x10
>
> # next command is more dangerous, because it intentionally destroys data
> on the slice (be careful about what you put in of=... )
> dd if=/dev/zero of=/dev/gpt/testslice bs=1M count=5000
>
> # after this command, you should have some checksum errors
> md5 /testpool/file
>
> # after this command and waiting, you should have all the errors there
> are (all files, including not read by the md5 above)
> zpool scrub testpool
>
> ...wait...
>
> zpool status testpool
>
> Now you probably (depending on whether or not the part we wrote with dd
> actually went on top of where data was placed) have checksum errors, and
> a message about an unrecoverable file. If it was raidz or mirror, it
> would have automatically fixed it for you, but with no redundancy, all
> the checksum can do is tell you the file is broken.
> _______________________________________________
> freebsd-fs at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"