From owner-freebsd-bugs@FreeBSD.ORG Tue May 10 17:20:11 2011 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C9331065672 for ; Tue, 10 May 2011 17:20:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1A4E68FC13 for ; Tue, 10 May 2011 17:20:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p4AHKAeE061317 for ; Tue, 10 May 2011 17:20:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p4AHKAsQ061316; Tue, 10 May 2011 17:20:10 GMT (envelope-from gnats) Resent-Date: Tue, 10 May 2011 17:20:10 GMT Resent-Message-Id: <201105101720.p4AHKAsQ061316@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, "D. Secret" Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D0B1106564A for ; Tue, 10 May 2011 17:14:40 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id 625338FC13 for ; Tue, 10 May 2011 17:14:40 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.4/8.14.4) with ESMTP id p4AHEdrH074977 for ; Tue, 10 May 2011 17:14:39 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id p4AHEdX2074976; Tue, 10 May 2011 17:14:39 GMT (envelope-from nobody) Message-Id: <201105101714.p4AHEdX2074976@red.freebsd.org> Date: Tue, 10 May 2011 17:14:39 GMT From: "D. Secret" To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: misc/156933: ZFS receive after read on readonly=on filesystem is corrupted without warning X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 17:20:11 -0000 >Number: 156933 >Category: misc >Synopsis: ZFS receive after read on readonly=on filesystem is corrupted without warning >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue May 10 17:20:10 UTC 2011 >Closed-Date: >Last-Modified: >Originator: D. Secret >Release: 8.2-RELEASE >Organization: >Environment: FreeBSD z0.L93.com 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Feb 17 02:41:51 UTC 2011 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 >Description: If you read from a readonly=on ZFS filesystem before receiving a ZFS -i send for new snapshots it will receive the new snapshot and have a corrupted filesystem(that ZFS scrub does not detect!) The one file on the filesystem I've included will show this corruption. It should simply be a file of consecutive numbers, yet the last like will have some messed up data. The ZFS 'images' were created as such: 13.zfs: A snapshot export of the filesystem -=- Append "14" to the replicate.dat file -=- Create snapshot @14 diff.zfs : a -i snapshot between @13 and @14. It properly re-creates the file assuming you haven't read from the filesystem. Note: Reading from the filesystem in this manner is present in some FAQ's about ZFS replication. >How-To-Repeat: 1. Create a new zfs filesystem zfs set readonly=on (my new filesystem) cat zimg/13.zfs | zfs receive -F (my new filesystem) OPTIONAL: cat (my new filesystem)/replicate.dat [This will cause the corruption if you do it] cat zimg/diff.zfs | zfs receive (my new filesystem) Now inspect (my new filesystem)/replicate.dat .. BUG file SHA1 is b3af2ae0f05cceb7efbcfc747750f56f53e4a69e Proper file SHA1 is 42f9e9bf4534b43b57faaed39194115bf3517898 You'll notice it'll be different depending on if you performed the "optional" step. I'm pretty sure this isn't proper. I've verified that the atime of the file isn't changing, but there must be some subtle change going on that isn't being caught. Also the zfs receive is allowed in both cases, but in one case the file is corrupted (vi shows 3x ^@ at the end, rather than the expected 14\n) I can offer you access to a machine if you have difficulty reproducing this issue. My scripts & sample filesystems are at: http://sov.L93.com/bug.tgz SHA1: 62b700d95096474ed7f3ae0b9249f9ec77e9a747 MD5: 9b9aa38b322cedd3e1223fc50f18a55b There are no executables, just a very simple 5 or so line (rather basic) script to automate things if you choose to use them. Please note it will destroy filesystem "z0/rdata_rcv" if you happen to have a ZFS filesystem by that name. ;) A shar archive of the 11k TGZ is 711k, beyond what i can attach to this. Hopefully the web link suffices. >Fix: I do not have a fix, but I do have what I believe is a 100% reproduction so I imagine a fix shouldn't be too difficult. I would look for what change is being made to the ZFS filesystem while readonly=on is set and a file is read...It should be none, as far as I know. >Release-Note: >Audit-Trail: >Unformatted: