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. Fix: maybe have dd abort if attempted to bitlevel write to zvolume or zpool. How-To-Repeat: try to dd onto zvolume.
Responsible Changed From-To: freebsd-bugs->freebsd-fs Over to maintainer(s).
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 >
On Fri, Sep 11, 2009 at 09:57:45AM -0400, Weldon S Godfrey 3 wrote: > > 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 Hmm, bascially you cannot write to directories directly: tank/foobar on /foo/bar (zfs, local) # dd if=/dev/zero of=/foo/bar bs=64k count=10000 dd: /foo/bar: Is a directory > 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. 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 > 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... -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am!
> 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.
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. > >
On Fri, Sep 11, 2009 at 11:48:59AM -0400, Weldon S Godfrey 3 wrote: > > 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. Ok. Thanks for the report. -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am!
State Changed From-To: open->feedback 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 I'll take this one.
State Changed From-To: feedback->closed Closed upon submitter's request.