> Hi,> > This is my proposal for a (hopefully) backwards compatible rd driver.> The motivation for me is not pressing, except that I have this code> sitting here that is either going to rot or get merged. I'm happy to> make myself maintainer of this code, but if any real block device> driver writer would like to, that would be fine by me ;)> > Comments?> > --> > This is a rewrite of the ramdisk block device driver.> > The old one is really difficult because it effectively implements a block> device which serves data out of its own buffer cache. It relies on the dirty> bit being set, to pin its backing store in cache, however there are non> trivial paths which can clear the dirty bit (eg. try_to_free_buffers()),> which had recently lead to data corruption. And in general it is completely> wrong for a block device driver to do this.> > The new one is more like a regular block device driver. It has no idea> about vm/vfs stuff. It's backing store is similar to the buffer cache> (a simple radix-tree of pages), but it doesn't know anything about page> cache (the pages in the radix tree are not pagecache pages).> > There is one slight downside -- direct block device access and filesystem> metadata access goes through an extra copy and gets stored in RAM twice.> However, this downside is only slight, because the real buffercache of the> device is now reclaimable (because we're not playing crazy games with it),> so under memory intensive situations, footprint should effectively be the> same -- maybe even a slight advantage to the new driver because it can also> reclaim buffer heads.

what about mmap(/dev/ram0)?

> The fact that it now goes through all the regular vm/fs paths makes it> much more useful for testing, too.> > text data bss dec hex filename> 2837 849 384 4070 fe6 drivers/block/rd.o> 3528 371 12 3911 f47 drivers/block/brd.o> > Text is larger, but data and bss are smaller, making total size smaller.> > A few other nice things about it:> - Similar structure and layout to the new loop device handlinag.> - Dynamic ramdisk creation.> - Runtime flexible buffer head size (because it is no longer part of the> ramdisk code).> - Boot / load time flexible ramdisk size, which could easily be extended> to a per-ramdisk runtime changeable size (eg. with an ioctl).

This ramdisk driver can use highmem whereas the existing one can't (yes?). That's a pretty major difference. Plus look at the revoltingness in rd.c'smapping_set_gfp_mask()s.