Date: Thu, 03 Oct 2002 14:56:35 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Mark Santcroos <marks@ripe.net> Cc: Bruce Evans <bde@zeta.org.au>, freebsd-hackers@FreeBSD.ORG, emulation@FreeBSD.ORG Subject: Re: vmware reads disk on non-sector boundary Message-ID: <3209.1033649795@critter.freebsd.dk> In-Reply-To: Your message of "Thu, 03 Oct 2002 13:56:49 %2B0200." <20021003115649.GC584@laptop.6bone.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20021003115649.GC584@laptop.6bone.nl>, Mark Santcroos writes: >On Thu, Oct 03, 2002 at 09:50:45PM +1000, Bruce Evans wrote: >> Unbreaking block devices would be a better solution. Without buffering, >> reads of raw disks using an unbuffered linux_read() might be <sector size> >> times slower than they should be. > >You are right. The quick and dirty hack I had in mind was less quick >and more dirty than I expected ;-) > >What was the reason for the removal of block devices anyway? >It would be nice if you would tell me some background about that.. :) It's well documented in the mail-archives actually. The short story: 1. We don't in general assign a special vnode type to device modes, instead we assign multiple device nodes, SCSI tapes is an example of this. 2. The vnode layer already have enough trouble aliasing /dev/fd0, /mnt/dev/fd0, /usr/jail/dev/fd0, /cdrom/dev/fd0 (you get the idea), we do not need to make it even harder by also aliasing /dev/fd0 and /dev/rfd0. 3. Write ordering on buffered devices were unspecified. In other words, you cannot use it for anything which even remotely smells of transactions, because you have no way to know when your writes have hit the disk and in which order they did so. 4. No write errors were reported back to userland. (Given 3 and 4, it follows that use of block devices for any sort of data you happen to like is a very bad idea.) 5. Block devices was in the way of getting DEVFS working in an architecturally sane manner. So they were removed, and good riddance. If a buffered access-mode on block devices is desired, it should be implemented either as an ioctl controllable feature, or as a GEOM module. The latter is probably by far the easiest way. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-emulation" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3209.1033649795>