Date: Mon, 2 Jun 1997 21:30:39 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: bugs@FreeBSD.ORG Cc: dgilbert@jaywon.pci.on.ca (David Gilbert) Subject: Re: Problems with CCD. Message-ID: <19970602213039.XS18169@uriah.heep.sax.de> In-Reply-To: <199706021711.NAA19380@repeat.pci.on.ca>; from David Gilbert on Jun 2, 1997 13:11:10 -0400 References: <199706010545.BAA16048@repeat.pci.on.ca> <199706020333.VAA00695@pluto.plutotech.com> <199706020426.AAA03842@repeat.pci.on.ca> <19970602082646.RS47657@uriah.heep.sax.de> <199706021711.NAA19380@repeat.pci.on.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
As David Gilbert wrote: > J> (Q: Tell me at least three > J> reasons why you should not use buffered devices for things like > J> newfs, or tar(1) to a floppy.) > > Can't ignore that... > > 1) /dev/rccd0c has one more character to type than /dev/ccd0c > 2) similarity (in tar's case) of st0 to ccd0 (have had experiences > where the raw tape device didn't work. > 3) many devices do their own buffering > 4) might eject the floppy too soon. 4) is one of my reasons, too. I've seen systems (DG/UX), where ``too soon'' was equal to ``anytime before the next reboot'' if the amount of data written to a buffered floppy devices was rather small. The only system call that guarantees you to wait until all buffers are flushed to the device is umount(2). Obviously, it requires a previous mount(2). A second reason is to not blast the buffercache, without any purpose. The third reason is that buffered writes report a `good' status to the application early, and if the actual writeback to the device fails later, the application cannot be notified of this. Only the administrator can be notified, using syslog. 1) is a valid argument. :-) 2) is a no-brainer. FreeBSD doesn't support buffered tape devives at all (and never did). You could in theory create a /dev/st0, the bdevsw entries are there, but this device won't actually work (i tried). 3) has nothing to do with all this. We talk about the buffer cache, not about device-level buffering which is fully transparent to the system. (Well, my reason #3 partly applies to this, too, you could get SCSI Deferred errors which the drivers only handle poorly.) Apart from your reason #1 :), there's only one valid point to use the buffered device: mounting a filesystem over it (or using it for swapon(8), which is related). This also holds valid for tape drives. Nobody uses filesystems on tapes these days. (I wanted to try it, that's why i've been experimenting with /dev/st0. :) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970602213039.XS18169>