cs4414: Operating Systems (rust-class.org) Class 17: Flash! Embedded notes are available at: rust-class.org/class-17-flash.... Segment 7: Log-Structured File Systems Write-Only File Systems Managing Meta-Data Log-Structured File Systems
If using this with spinning rust wouldn't it make sense to implement one file system that spanned several disks? * When re-collecting sparse valid blocks during garbage collection, one disk can be reading, while another is writing. This would mean that disk1 is writing in the non-valid blocks until it gets to a valid block. No seek. It reads that block, which is then written by disk 2, and it can continue to use disk1. * A lot of chunks of disk are unread for very long periods of time. So you want some sort of hierarchy of segments on each disk depending on how frequently a given file is likely to be read. So when collecting, when the OS finds a file in the way that hasn't been used for several months, instead of writing it on the currently active tail, it gets written to the snooze disk. This in principle is a good use for older hardware that isn't as fast. * At this same time, I really like the concept of ZFS where every block contains a checksum, with periodic 'resilvering' that checks and reconstructs bit errors. *** With the price of flash at present, using a flash drive as the primary file system, and a disk as the secondary one makes lots of sense. Are hybrid drives built this way? *** On flash drives, while erase is expensive, seeks are not. *** Merit in keeping some form of data in the imap as to the relative age of the inode? If with each generation of the imap, a counter for each inode is incremented by one, except for the inodes just written, then the current imap becomes a table of what should be shuffled off to a slow turnover segment.
