kern/138244: dd attempts bitwise transfer onto ZFS pool

[Weldon Godfrey]

>Number:         138244
>Category:       kern
>Synopsis:       dd attempts bitwise transfer onto ZFS pool
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Aug 27 19:00:09 UTC 2009
>Closed-Date:
>Last-Modified:
>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 at 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:
>Unformatted: