Date: Sun, 10 Oct 1999 18:21:04 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Julian Elischer <julian@whistle.com> Cc: Bruce Evans <bde@zeta.org.au>, freebsd-arch@FreeBSD.ORG, mckusick@mckusick.com, committers@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: The eventual fate of BLOCK devices. Message-ID: <199910110121.SAA18665@apollo.backplane.com> References: <Pine.BSF.4.10.9910101323201.12493-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:> > 6/ It should be possible to make an overlay device (similar to the way :> > ccd works), that supplies buffered characteristics to a disk. This may :> > be a different minor number or a differnt major number.. but be a CHR :> > type device. :> :> This would involve needless duplicatication of half of the buffer cache :> implementation (maybe the simple half) unless the buffer cache goes away. :> :> Bruce It should be noted that the current implementation of block devices is fairly trivial, only a few dozen lines of code. I agree with Bruce: it would be silly to throw that away and spend days rewriting it. There is nothing wrong with block device's that can't be trivially fixed other then the fact that Poul seems rabidly intent on destroying them, and there isn't anything wrong with using filesystem buffers either. It should also be noted that in order to maintain cache coherency between read/write and mmap() on a block device, you either have to go through the buffer cache or you have to rewrite considerably more then just specfs. There are several trivial ways to solve the write-error problem. First, implement writes as write-through so a synchronous error can be returned. Second, implement an error code on close. There are other possibilities as well, such as implementing a single buffer pipeline and returning a delayed error, which preserves some of the write pipelining performance, or implementing an intermediate backing layer (such as swap) to buffer errored blocks for later retrieval. There are also situations where errors can be assumed to not occur, such as when using buffered VN partition which is backed by a file or swap. It isn't inconceivable that the methodology could be selected with an ioctl(), with the write-through-synchronous-return for writes made the default. This is all of a dozen lines of code. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199910110121.SAA18665>