Re: write alignment matters?

[Reinoud Zandijk <reinoud%NetBSD.org@localhost>]

On Fri, Jun 24, 2011 at 04:39:13PM +0000, David Holland wrote:
> On Fri, Jun 24, 2011 at 11:33:51AM -0400, der Mouse wrote:
>  > >> Oh, I was talking about current NetBSD where block devices are a
>  > >> second class citizen, soon to be abolished if someone finds enough
>  > >> round tuits.
>  > > Yes, so it keeps being said.  It would truly be a pity to see that
>  > > happen.
>  > 
>  > Why?
> 
> Why which? :-)
> 
> The current problem is that the block device is connected to the old
> pre-UBC buffer cache now used only for metadata blocks, so various
> problems (consistency, starvation, etc.) can occur if you start using
> it for bulk I/O. There's also a problem that the buffer cache code
> wasn't ever designed to cope with removable devices, so bad things
> happen if you try to use the block device for something that isn't
> there (e.g. a floppy drive with no media in it) or that you eject
> before writeback has completed.

Maybe a revolutionary thing to say, but can't we make the block devices use
UBC too? Its not that different from reading a file after all.

Existing users of the buffer-cache can then be given a method of coupling some
buffers to a node instead of using the negative number scheme. Directory
contents can also be stored in UBC, fs/udf has done that as long as it exists.

> I assume the reason it would be a pity to see it go is that (when
> working properly) it's useful functionality, even if used rarely or
> only in specialized circumstances. Also, for applications like online
> defrag or whatnot, using a (properly unified) block device is delicate
> but using a raw device is entirely infeasible.
indeed

> My current intent is to tackle the buffer cache when/if I ever finish
> grinding namei and namei-related vfs stuff, because the lack of full
> unification bugs me and the build quality of the old buffer code
> concerns me.

see above,
Reinoud