On Tue, Jan 10, 2017 at 10:42:45AM +0900, Damien Le Moal wrote: > Thank you for the information. I will check this out. Is it the > optimization that aggressively delay meta-data update by allowing > reading of meta-data blocks directly from the journal (for blocks that > are not yet updated in place) ? Essentially, yes. In some cases, the metadata might never be written back to its permanent location in disk. Instead, we might copy a metadata block from the tail of the journal to the head, if there is enough space. So effectively, it turns the journal into a log structured store for metadata blocks. Over time, if metadata blocks become cold we can evict them from the journal to make room for more frequently updated metadata blocks (given the currently running workload). Eliminating the random 4k updates to the allocation bitmaps, inode table blocks, etc., really helps with host-aware SMR drives, without requiring the massive amount of changes needed to make a file system compatible with the host-managed model. When you consider that for most files, they are never updated in place, but are usually just replaced, I suspect that with some additional adjustments to a traditional file system's block allocator, we can get even further wins. But that's for future work... > Emulators may indeed be very useful for development. But we could also > go further and implement the different models using device mappers too. > Doing so, the same device could be used with different FTL through the > same DM interface. And this may also simplify the implementation of > complex models using DM stacking (e.g. the host-aware model can be > implemented on top of a host-managed model). Yes, indeed. That would also allow people to experiment with how much benefit can be derived if we were to give additional side channel information to STL / FTL's --- since it's much easier to adjust kernel code than to go through a negotiations with a HDD/SSD vendor to make firmware changes! This may be an area where if we can create the right framework, and fund some research work, we might be able to get some researchers and their graduate students interested in doing some work in figuring out what sort of divisions of responsibilities and hints back and forth between the storage device and host have the most benefit. Cheers, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
