Date: Sat, 21 Feb 1998 15:42:56 -0800 From: John-Mark Gurney <gurney_j@efn.org> To: Daniel Ortmann <ortmann@sparc.isl.net> Cc: freebsd-bugs@FreeBSD.ORG Subject: Re: bin/5755 Message-ID: <19980221154256.11361@hydrogen.nike.efn.org> In-Reply-To: <199802201442.IAA03788@pyrl.eye>; from Daniel Ortmann on Fri, Feb 20, 1998 at 08:42:00AM -0600 References: <199802191358.FAA18191@freefall.freebsd.org> <199802201442.IAA03788@pyrl.eye>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Ortmann scribbled this message on Feb 20: > > 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. well... it's more of a matter of what does a disk device do when you only write out a partial block? does it read in the block (which might not be possible) and just add the data you wrote? or does it pad the block... to be save it just drops the request... which is logical... also, the output of dd stated what was happening... the <complete blocks>+<bytes of partial block> really said it all... on your raw device write, it showed that the partial block didn't get writen (it was x+0), while the read had x+y... > 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? see above... also, the raw character device is actually a way for the user to by-pass the buffering that the system does on the block device and hit the device directly... so when using the raw device your at the mercy of that it provides... most disks don't provide the ability to write just 5 bytes, you have to write a whole block.. > 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". well.. if you did turn on conv=osync by default then when you dd'd between two files, the output file would get a bunch of nulls at the end (which I'm sure you don't want) because the default block size of dd is 512b... > (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.:-) well, the problem is there isn't anything that can be fixed in this case.. if you fix it for block devices (by defaulting osync), then you break it for files... and personally, I only spent maybe a few minutes reading dd's man page to find all the relavent info... (of course I was also familar with the conv= stuff as I reciently started to write scripts using the block and unblock features of dd for tape indexing)... -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking P.O. Box 5693, 97405 Live in Peace, destroy Micro$oft, support free software, run FreeBSD Don't trust anyone you don't have the source for To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980221154256.11361>