From owner-freebsd-fs@FreeBSD.ORG Wed Feb 8 19:31:40 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C95C106578E for ; Wed, 8 Feb 2012 19:31:40 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from mo-p05-ob6.rzone.de (mo-p05-ob6.rzone.de [IPv6:2a01:238:20a:202:53f5::1]) by mx1.freebsd.org (Postfix) with ESMTP id 8906D8FC17 for ; Wed, 8 Feb 2012 19:31:39 +0000 (UTC) X-RZG-AUTH: :LWIKdA2leu0bPbLmhzXgqn0MTG6qiKEwQRWfNxSw4HzYIwjsnvdDt2QV8d370mKouLGgFPM= X-RZG-CLASS-ID: mo05 Received: from [192.168.179.39] (hmbg-4d069da4.pool.mediaWays.net [77.6.157.164]) by smtp.strato.de (fruni mo41) (RZmta 27.6 DYNA|AUTH) with (DHE-RSA-AES128-SHA encrypted) ESMTPA id i04a38o18IkjaI for ; Wed, 8 Feb 2012 20:31:16 +0100 (MET) Message-ID: <4F32CD83.6000101@brockmann-consult.de> Date: Wed, 08 Feb 2012 20:31:15 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <20120208184728.GH6814@zero> <4F32CD14.1030508@brockmann-consult.de> In-Reply-To: <4F32CD14.1030508@brockmann-consult.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: zfs checksums on non-raidz X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 19:31:40 -0000 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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"