From owner-freebsd-questions Sat Nov 15 15:12:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA02839 for questions-outgoing; Sat, 15 Nov 1997 15:12:44 -0800 (PST) (envelope-from owner-freebsd-questions) Received: from clio.rice.edu (clio.rice.edu [128.42.105.3]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA02831 for ; Sat, 15 Nov 1997 15:12:37 -0800 (PST) (envelope-from keyser@clio.rice.edu) Received: by clio.rice.edu (AIX 3.2/UCB 5.64/4.03) id AA16619; Sat, 15 Nov 1997 17:14:27 -0600 Date: Sat, 15 Nov 1997 17:14:27 -0600 From: keyser@clio.rice.edu (Kevin Keyser) Message-Id: <9711152314.AA16619@clio.rice.edu> To: doug@bigwheel.net Subject: Re: char and block devices (was: image file of a floppy) Cc: questions@freebsd.org Sender: owner-freebsd-questions@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >I believe you should be using /dev/rfd0 as the device file name. > > Thanks, Kevin. Apparently you are quite right. Since my post > I have more-less deduced that the "r" in front of a device name > indicates the raw device. So, it would appear that the block > device is used to create an image file from the diskette and > the raw device is used to write an image file to a diskette. I think that even though you are getting away with it on the read, you should use raw devices in either case with dd. > I'm not sure that I understand why. If you happen to know and > have the time to share, I'd love to be enlightened. OK, I'll give it a try trusting that someone on this list will quickly correct me if I'm wrong. :-) So don't bet your life on this just yet. Disks have both character and block device interfaces, such as rfd0 and fd0 for the first floppy. To use the character interface, a program must obey the block size (generally 512 bytes) when specifying offsets and amounts for a transfer (ie. they must be multiples of 512). The transfer is done directly to the program address space. This kind of fits the nature of dd (among others). The block device allows the user program to specify offsets and sizes for transfers that do not fall on sector boundaries by doing the math to decide which whole blocks need to actually be read (to a buffer in the kernel) and then copying precisely what the user program asked for to/from that program's address space. So there is this extra copy step but this also means that subsequent accesses to the same data can be serviced from the kernel buffers (if still intact) without having to synchronously access the disk every time. This kind of fits with filesystem access, so you always mount the block device. Now, what I can't specifically explain is why dd and/or the whole system loses its mind if you try to go through the block device. I am interested in understanding this better. Anyone? > Thanks ever so much for the enlightening you've already done. Any time. > ... doug > _____________________________________________________________________ > Doug Jolley mailto://doug@bigwheel.net http://www.bigwheel.net > Don't bogart that file, my friend. Net it over to me. > --------------------------------------------------------------------- Kevin