<quote> SCST using FILEIO is blindingly fast but I don't know of any serious storage architects that are going to trust 50-60 gigabytes of a database or filesystem to the Linux pagecache and associated vagaries of VM writeback behavior. </quote>
Maybe it's not much and with memory footprints that big, my solution is too small. But why not write the EXT3/4 journal to a NVRAM board? The 512MB ones are pretty darn cheap on EBAY. I've got a fistful myself. If you journal meta+data at least you have recovery points. Otherwise a RAID set of high-quality SSD could be a reliable journal, no? Linux VFS has lots of tunables, and I think you'd be able to find a happy medium between absorbing sudden, big writes, and reliably de-staging to disk. I wish EXT4/XFS et. al. had the ability to do round-robbin journaling ala Oracle LogWriter so that once the first chunk of ~256MB was written to the journal everything didn't come to a screeching stop until the corresponding bits got written out to 'permanent' storage. But I guess at that point maybe the answer is to use ZFS? > block based interface to RAM I could have sworn there already was such a driver...Yeah 'brd'. Did that not fit the intended use? http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/drivers/block/brd.c and another exercise http://www.linuxforu.com/2012/02/device-drivers-disk-on-ram-block-drivers/ though this one is probably more interesting yet http://rapiddisk.org/index.php?title=Changelog http://rapiddisk.org/index.php?title=RapidCache -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
