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
