From owner-freebsd-bugs Sat Feb 21 13:59:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA24501 for freebsd-bugs-outgoing; Sat, 21 Feb 1998 13:59:01 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from pyrl.eye (ppp-33.isl.net [199.3.25.82]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA24491; Sat, 21 Feb 1998 13:58:52 -0800 (PST) (envelope-from ortmann@sparc.isl.net) Received: (from ortmann@localhost) by pyrl.eye (8.8.8/8.8.8) id IAA03788; Fri, 20 Feb 1998 08:42:00 -0600 (CST) (envelope-from ortmann) From: Daniel Ortmann Message-Id: <199802201442.IAA03788@pyrl.eye> Subject: Re: bin/5755 In-Reply-To: <199802191358.FAA18191@freefall.freebsd.org> from John-Mark Gurney at "Feb 19, 98 05:58:45 am" To: jmg@FreeBSD.ORG (John-Mark Gurney) Date: Fri, 20 Feb 1998 08:42:00 -0600 (CST) Cc: ortmann@sparc.isl.net, jmg@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Synopsis: dd drops block when of=/dev/rfd0a > > State-Changed-From-To: open-closed > State-Changed-By: jmg > State-Changed-When: Thu Feb 19 05:56:10 PST 1998 > State-Changed-Why: > some device have a minimum size that you can write to... mose disk devices > have a min of 512bytes... to write the final block out to disk, also add > conv=osync to the dd line which will force the final block to be writen... > > # dd if=as of=/dev/rda1b conv=osync > 0+1 records in > 1+0 records out > 512 bytes transferred in 0.004164 secs (122959 bytes/sec) > # ls -l as > -rw-r--r-- 1 jmg jmg 13 Feb 19 05:53 as If performing a logical operation such as "so many bytes in from this source and so many out to this destination" behaves differently depending on the output device, then that seems like a bug to me. Similar to a programming "side effect" error or an unchecked-for case. Carefully said, due to my lack of information in this area, if the problem is not actually with dd, then perhaps there is a larger device driver architecture issue that could be addressed to make this dd behavior possible? Is there a valid reason for not having this conv=osync option on by default? That is, other than "we've always done it that way". (Perhaps this should be resubmitted as a "feature request". I certainly was caught by surprise, especially since my purpose was to fix a crashed computer and not to pour through the dd manual.:-) -- Daniel Ortmann 507.288.7732 (h) ortmann@isl.net 2414 30 av NW, #D 507.253.6795 (w) ortmann@vnet.ibm.com Rochester, MN 55901 "PERL: The Swiss Army Chainsaw" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message