From nobody@FreeBSD.org  Thu Aug 27 18:53:49 2009
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id E2A2210656C4
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 27 Aug 2009 18:53:49 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id D18688FC47
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 27 Aug 2009 18:53:49 +0000 (UTC)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.3/8.14.3) with ESMTP id n7RIrnxs070757
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 27 Aug 2009 18:53:49 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.3/8.14.3/Submit) id n7RIrn07070748;
	Thu, 27 Aug 2009 18:53:49 GMT
	(envelope-from nobody)
Message-Id: <200908271853.n7RIrn07070748@www.freebsd.org>
Date: Thu, 27 Aug 2009 18:53:49 GMT
From: Weldon Godfrey <weldon@excelsusphoto.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: dd attempts bitwise transfer onto ZFS pool
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         138244
>Category:       kern
>Synopsis:       [zfs] dd(1) attempts bitwise transfer onto ZFS pool
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    pjd
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Aug 27 19:00:09 UTC 2009
>Closed-Date:    Sat Sep 12 07:30:59 UTC 2009
>Last-Modified:  Sat Sep 12 07:40:08 UTC 2009
>Originator:     Weldon Godfrey
>Release:        8.0-CURRENT (Dec 12)
>Organization:
>Environment:
FreeBSD store1.mail.ena.net 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Fri Dec 12 10:00:24 CST 2008     root@store1.mail.ena.net:/usr/obj/usr/src/sys/GENERIC  amd64
>Description:

I am completely guessing this, please forgive me if the following is moronic or wrong, either completely or partially:

Accidentally, we tried to dd onto a ZFS volume, it claimed it wrote like a gig before aborted.  What appeared to happen: the filesystem showed empty after dd was aborted, which would be expected of an aborted dd.  zfs rollback caused system panic (which turned out to be a blessing).

Upon reboot, filesystem was back without any damage (all files exist prior to dd and not rolled back).  I am guessing this is because:
1.  ZFS code doesn't allow bit level copying onto a zpool or zvolume, which is fine.  Of course, you could use dd to bit level copy each raw disk to copy a zfs system, but that is not the point of this ticket
2.  FreeBSD had a rather large filesystem cache (since this system has like 16GB of RAM)...since the zvolume mountpoint appears like any normal mounted disk, it performed the bit level operation against the zvolume and zeroed out the filesystem cache in memory.  
3.  When freebsd tried to flush this cache, zfs code didn't perform it because it isn't supported, so it never wrote to disks.  However, filesystem cache is now inconsistant
4.  The inconsistant state was discovered near (or because of) the zfs rollback, kernel paniced and rebooted


If I am correct, and I know I am VERY likely wrong...maybe the code for dd needs to detect for someone trying to dd onto a zvolume or zpool and just abort gracefully, without touching filesystem cache.

>How-To-Repeat:
try to dd onto zvolume.
>Fix:
maybe have dd abort if attempted to bitlevel write to zvolume or zpool.

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-fs 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Thu Aug 27 19:46:17 UTC 2009 
Responsible-Changed-Why:  
Over to maintainer(s). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=138244 
State-Changed-From-To: open->feedback 
State-Changed-By: pjd 
State-Changed-When: pon 7 wrz 2009 11:46:04 UTC 
State-Changed-Why:  
I'm sorry, but I don't really understand what you described. 

What do you mean by 'bitwise transfer'? Writing to raw block device 
like /dev/da0? 

What do you mean by zvolume? I think you mean raw device used as pool 
component, but in ZFS terminology zvolume (ZVOL) is something different. 

What do you mean by 'bit level copying onto a zpool'? zpool is not a block 
device. Do you mean copying to /pool/ directory or block device which is 
pool component? 

Could you show example commands you were trying to use, your pool 
configuration, etc.? 

If you ment to do something like 'dd if=/dev/zero of=/dev/da0' where da0 
is pool component (a vdev in ZFS terminology) then it should be denied by 
GEOM, as da0 should be already opened for writing by ZFS and dd(1) shouldn't 
be able to open it for writing at all. 


Responsible-Changed-From-To: freebsd-fs->pjd 
Responsible-Changed-By: pjd 
Responsible-Changed-When: pon 7 wrz 2009 11:46:04 UTC 
Responsible-Changed-Why:  
I'll take this one. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=138244 

From: Weldon S Godfrey 3 <weldon@excelsusphoto.com>
To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org
Cc: pjd@FreeBSD.org
Subject: Re: kern/138244: dd attempts bitwise transfer onto ZFS pool
Date: Fri, 11 Sep 2009 09:57:45 -0400 (EDT)

 Sorry, I lost the reply to this
 
 the command was:
 
 dd if=/dev/zero of=/export/store1-1 bs=64k count=10000
 the 'of' was an accident,  it was meant to be to a file and not the 
 mountpoint
 here is the df
 tank/store1-1     2882037632 1161418880 1720618752    40% 
 /export/store1-1
 
 sorry, I didn't execute this and I misunderstood what happened.   I 
 thought the 'of' was to tank/store1-1 so this may not be 
 such an issue.
 
 I personally never tested to see if you use the mountpoint 
 instead of the /dev special file (or zfs volume in this case) with the 'of 
 argument in dd, would dd treat the mountpoint as if it was the /dev 
 special file.
 
 however, the result was understood correctly, it zeroed out the dir, it 
 appeared in FreeBSD as if it was blank.  I tried to do a rollback but that 
 caused the system to panic.  Which turned out to be great, the system came 
 back fine (not zeroed out) and not rolled back (as it was before the dd 
 comand was executed).
 
 sorry, this may not be an issue at all.  we are happy that zfs didn't kill 
 the data on this accident.
 
 going to just /export/store1-1 was an accident
 
 If memory serves me right, sometime around Aug 27, FreeBSD-gnats-submit@Fre...:
 
 > Thank you very much for your problem report.
 > It has the internal identification `kern/138244'.
 > The individual assigned to look at your
 > report is: freebsd-bugs.
 >
 > You can access the state of your problem report at any time
 > via this link:
 >
 > http://www.freebsd.org/cgi/query-pr.cgi?pr=138244
 >
 >> Category:       kern
 >> Responsible:    freebsd-bugs
 >> Synopsis:       dd attempts bitwise transfer onto ZFS pool
 >> Arrival-Date:   Thu Aug 27 19:00:09 UTC 2009
 >

From: Pawel Jakub Dawidek <pjd@FreeBSD.org>
To: Weldon S Godfrey 3 <weldon@excelsusphoto.com>
Cc: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org
Subject: Re: kern/138244: dd attempts bitwise transfer onto ZFS pool
Date: Fri, 11 Sep 2009 17:29:34 +0200

 --SWTRyWv/ijrBap1m
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Fri, Sep 11, 2009 at 09:57:45AM -0400, Weldon S Godfrey 3 wrote:
 >=20
 > Sorry, I lost the reply to this
 >=20
 > the command was:
 >=20
 > dd if=3D/dev/zero of=3D/export/store1-1 bs=3D64k count=3D10000
 > the 'of' was an accident,  it was meant to be to a file and not the=20
 > mountpoint
 > here is the df
 > tank/store1-1     2882037632 1161418880 1720618752    40%=20
 > /export/store1-1
 
 Hmm, bascially you cannot write to directories directly:
 
 	tank/foobar on /foo/bar (zfs, local)
 	# dd if=3D/dev/zero of=3D/foo/bar bs=3D64k count=3D10000
 	dd: /foo/bar: Is a directory
 
 > sorry, I didn't execute this and I misunderstood what happened.   I=20
 > thought the 'of' was to tank/store1-1 so this may not be=20
 > such an issue.
 >=20
 > I personally never tested to see if you use the mountpoint=20
 > instead of the /dev special file (or zfs volume in this case) with the 'o=
 f=20
 > argument in dd, would dd treat the mountpoint as if it was the /dev=20
 > special file.
 
 dd(1) simply use open(2) to open the 'of' target. If you can't for
 example ls(1) the target you won't be able to use it for dd(1).
 
 > however, the result was understood correctly, it zeroed out the dir, it=
 =20
 > appeared in FreeBSD as if it was blank.  I tried to do a rollback but tha=
 t=20
 > caused the system to panic.  Which turned out to be great, the system cam=
 e=20
 > back fine (not zeroed out) and not rolled back (as it was before the dd=
 =20
 > comand was executed).
 >=20
 > sorry, this may not be an issue at all.  we are happy that zfs didn't kil=
 l=20
 > the data on this accident.
 
 You must misinterpret something, because it is not possible to write to
 a directory...
 
 --=20
 Pawel Jakub Dawidek                       http://www.wheel.pl
 pjd@FreeBSD.org                           http://www.FreeBSD.org
 FreeBSD committer                         Am I Evil? Yes, I Am!
 
 --SWTRyWv/ijrBap1m
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.4 (FreeBSD)
 
 iD8DBQFKqmzeForvXbEpPzQRAq+jAJ0UavBVoN71IGuRWk3kkCU/hMkulgCcDvqt
 5FtnIpxISX+Etog2BtjY04Y=
 =swIg
 -----END PGP SIGNATURE-----
 
 --SWTRyWv/ijrBap1m--

From: Weldon S Godfrey 3 <weldon@excelsusphoto.com>
To: Pawel Jakub Dawidek <pjd@FreeBSD.org>
Cc: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org
Subject: Re: kern/138244: dd attempts bitwise transfer onto ZFS pool
Date: Fri, 11 Sep 2009 11:39:27 -0400 (EDT)

 > example ls(1) the target you won't be able to use it for dd(1).
 >
 >> however, the result was understood correctly, it zeroed out the dir, it
 >> appeared in FreeBSD as if it was blank.  I tried to do a rollback but that
 >> caused the system to panic.  Which turned out to be great, the system came
 >> back fine (not zeroed out) and not rolled back (as it was before the dd
 >> comand was executed).
 >>
 >> sorry, this may not be an issue at all.  we are happy that zfs didn't kill
 >> the data on this accident.
 >
 > You must misinterpret something, because it is not possible to write to
 > a directory...
 >
 The engineer pulled the command from the history, so it is correct.
   When he freaked out from executing that, I went to the console he was on, 
 did an 'ls' and 'pwd' of the directory that he did it to, it was empty. 
 So at least, however, old(dec 2008) version of head, dd did something bad.
 

From: Weldon S Godfrey 3 <weldon@excelsusphoto.com>
To: Pawel Jakub Dawidek <pjd@FreeBSD.org>
Cc: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org
Subject: Re: kern/138244: dd attempts bitwise transfer onto ZFS pool
Date: Fri, 11 Sep 2009 11:48:59 -0400 (EDT)

 Humm, yeah, I can't recreate it, I am not sure why it happened that day. 
 Go ahead and close.  If it happens after we upgrade (which we plan after 
 8.0 goes to RELEASE and during downtime), i'll let you know.
 
 Thanks for looking it to it.
 
 If memory serves me right, sometime around 11:39am, Weldon S Godfrey 3 told me:
 
 >
 >> example ls(1) the target you won't be able to use it for dd(1).
 >> 
 >>> however, the result was understood correctly, it zeroed out the dir, it
 >>> appeared in FreeBSD as if it was blank.  I tried to do a rollback but that
 >>> caused the system to panic.  Which turned out to be great, the system came
 >>> back fine (not zeroed out) and not rolled back (as it was before the dd
 >>> comand was executed).
 >>> 
 >>> sorry, this may not be an issue at all.  we are happy that zfs didn't kill
 >>> the data on this accident.
 >> 
 >> You must misinterpret something, because it is not possible to write to
 >> a directory...
 >> 
 > The engineer pulled the command from the history, so it is correct.
 > When he freaked out from executing that, I went to the console he was on, did 
 > an 'ls' and 'pwd' of the directory that he did it to, it was empty. So at 
 > least, however, old(dec 2008) version of head, dd did something bad.
 >
 >
State-Changed-From-To: feedback->closed 
State-Changed-By: pjd 
State-Changed-When: sob 12 wrz 2009 07:30:37 UTC 
State-Changed-Why:  
Closed upon submitter's request. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=138244 

From: Pawel Jakub Dawidek <pjd@FreeBSD.org>
To: Weldon S Godfrey 3 <weldon@excelsusphoto.com>
Cc: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org
Subject: Re: kern/138244: dd attempts bitwise transfer onto ZFS pool
Date: Sat, 12 Sep 2009 09:31:27 +0200

 --uZ3hkaAS1mZxFaxD
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Fri, Sep 11, 2009 at 11:48:59AM -0400, Weldon S Godfrey 3 wrote:
 >=20
 > Humm, yeah, I can't recreate it, I am not sure why it happened that day.=
 =20
 > Go ahead and close.  If it happens after we upgrade (which we plan after=
 =20
 > 8.0 goes to RELEASE and during downtime), i'll let you know.
 
 Ok. Thanks for the report.
 
 --=20
 Pawel Jakub Dawidek                       http://www.wheel.pl
 pjd@FreeBSD.org                           http://www.FreeBSD.org
 FreeBSD committer                         Am I Evil? Yes, I Am!
 
 --uZ3hkaAS1mZxFaxD
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.4 (FreeBSD)
 
 iD8DBQFKq05PForvXbEpPzQRAoIOAKCTHg7PIs83KlMxWIbOuF/aizsCfwCghpNV
 nzfHRvAIBKo6gOTf3e23NB4=
 =Q4m9
 -----END PGP SIGNATURE-----
 
 --uZ3hkaAS1mZxFaxD--
>Unformatted:
