On Apr 6, 2018, at 4:27 PM, Theodore Y. Ts'o <tytso@xxxxxxx> wrote: > The other thing to consider is whether it makes any sense at all to > solve this problem by haing a single file system where part of the > storage is DAX, and part is not. Why not just have two file systems, > one which is 100% DAX, and another which is 100% HDD/SSD, and store > the data in two files in two different file systems? I think there definitely *are* benefits to having both flash and HDDs (and/or other different storage classes such as RAID-10 and RAID-6) in the same filesystem namespace. This is the premise behind bcache, XFS realtime volumes, Btrfs, etc. That said, having a hard-coded separation of flash vs. disks does not make sense, even from an intermediate development point of view. There definitely should be a block-device interface for querying what the actual layout is, perhaps something like the SMR zones? Alternately, ext4 could add something akin to the realtime volume in XFS, where it can directly address multiple storage devices to handle different storage classes, but that would need at least some amount of development. It was actually one of the options on the table for the early ext2resize development, to split the ext4 block groups across devices and then concatenate them logically at runtime. That would allow e.g. some number of DAX block groups, NVMe block groups, and HDD RAID-6 block groups all in the same filesystem. Even then, there would need to be some way for ext4 to query the storage type of the underlying devices, so that these could be mapped to the lifetime hints. Cheers, Andreas
Attachment:
signature.asc
Description: Message signed with OpenPGP
