:> > 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
