On Fri, Aug 19, 2016 at 10:01:43PM +0200, Jose Luis Rodriguez Garcia wrote: > On Fri, Aug 19, 2016 at 5:27 PM, Thor Lancelot Simon > > > > Perhaps, but I bet it'd be easier to implement a generic pseudodisk > > device that used NVRAM (fast SSD, etc -- just another disk device really) > > to buffer *all* writes to a given size and feed them out in that-size > > chunks. Or to add support for that to RAIDframe. > > > > For bonus points, do what the better "hardware" RAID cards do, and if > > the inbound writes are already chunk-size or larger, bypass them around > > the buffering (it implies extra copies and waits after all). > > > > That would help LFS and much more. And you can do it without having > > to touch the LFS code. > > Won't it be easier to add a layer that do these tasks in > the LFS code. It has the disadvantage that it would be used only by
I am guessing not. The LFS code is very large and complex -- much more so than it needs to be. It is many times the size of the original Sprite LFS code, which, frankly, worked better in almost all ways. It represents (to me) a failed experiment at code and datastructure sharing with FFS (it is also worse, and larger, because Sprite's buffer cache and driver APIs were simpler than ours and better suited to LFS' needs). It is so large and so complex that truly screamingly funny bugs like writing the blocks of a segement out in backwards order went undetected for long periods of time! It might be possible to build something like this inside RAIDframe or LVM but I think it would share little code with any other component of those subsystems. I would suggest building it as a standalone driver which takes a "data disk" and "cache disk" below and provides a "cached disk" above. I actually think relatively little code should be required, and avoiding interaction with other existing filesystems or pseudodisks should keep it quite a bit simpler and cleaner. Thor
