Date: Wed, 08 Feb 2012 20:29:24 +0100 From: Peter Maloney <peter.maloney@brockmann-consult.de> To: freebsd-fs@freebsd.org Subject: Re: zfs checksums on non-raidz Message-ID: <4F32CD14.1030508@brockmann-consult.de> In-Reply-To: <20120208184728.GH6814@zero> References: <20120208184728.GH6814@zero>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F32CD14.1030508>