From owner-freebsd-bugs@FreeBSD.ORG Fri Sep 11 15:49:01 2009 Return-Path: Delivered-To: freebsd-bugs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4DBE1065679 for ; Fri, 11 Sep 2009 15:49:01 +0000 (UTC) (envelope-from weldon@excelsusphoto.com) Received: from mx0.excelsus.net (emmett.excelsus.com [74.93.113.252]) by mx1.freebsd.org (Postfix) with ESMTP id 59ED48FC12 for ; Fri, 11 Sep 2009 15:49:00 +0000 (UTC) Received: (qmail 59320 invoked by uid 89); 11 Sep 2009 15:48:59 -0000 Received: from unknown (HELO localhost) (127.0.0.1) by localhost.excelsus.com with SMTP; 11 Sep 2009 15:48:59 -0000 Date: Fri, 11 Sep 2009 11:48:59 -0400 (EDT) From: Weldon S Godfrey 3 X-X-Sender: weldon@emmett.excelsus.com To: Pawel Jakub Dawidek In-Reply-To: Message-ID: References: <200908271900.n7RJ09Ax095497@freefall.freebsd.org> <20090911152934.GE1673@garage.freebsd.pl> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-bugs@FreeBSD.org, FreeBSD-gnats-submit@FreeBSD.org Subject: Re: kern/138244: dd attempts bitwise transfer onto ZFS pool 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: Fri, 11 Sep 2009 15:49:01 -0000 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. > >