Hi Andreas, > In the absence of other information, the Stream ID would just mean "group > allocations with the same ID together". After some discussion, it looks > like the latest patch has generic "lifetime" hints rather than "stream IDs", > but the end result is largely the same. I looked up the links you provided for StreamID which provides lifetime hints for a file. In our case we have different importance levels/grade levels pertaining to different blocks of a single file itself. I am not sure if akin to lifetime hints, different *allocation type hint* can be achieved by using StreamID. However I am yet to read details about the concept of StreamID to see if we can use StreamID to our advantage in allocations of different blocks of a single file to separate tiers, as well as in providing a reduced view. Any insight on this would be really helpful. > series instead of trying to introduce a new interface. IMHO, there is > no need to make these hints persistent on disk, since their state could > be inferred by the allocation placement directly The problem with not making the hints persistent can be 1) if the higher graded block got stored in HDD due to for e.g - overflowing of the higher tier, but is critical from application point of view(can be accessed from hdd in case of our code) and, 2) to preserve grade information even when the file is copied : Suppose the higher tier gets full, thus we store the high graded blocks of file in the lower tier, and after storing we delete the grade metadata as well. Now if we copy this file to some other mixed block device which has sufficient space in higher tier we would still not be able to store that high graded block in higher tier here (in case of inferring the state by the allocation placement). > 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? Yes, I agree, that the ideal situation would be to have a mechanism to identify the segment boundaries automatically inside the LVM. But we were not able to get a method to access the boundaries or rather the location of a free block in each segment by such system call. So, in order to just test out the system we proceeded by hardcoding the boundaries as per our simulated LVM. But since this is not practical we provided the TODO/FIX IT in those areas. We are still looking for a good mechanism, and would welcome any advice/suggestions. Also, we chose to use Ext4 since it is generally the most commonly used file system in linux based systems. However, I am not aware if the problem of getting the boundaries can be solved in a simpler manner by using XFS. Regards, Sayan Ghosh On Mon, Apr 9, 2018 at 9:33 AM, Andreas Dilger <adilger@xxxxxxxxx> wrote: > 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 > > > > > </tytso@xxxxxxx></adilger@xxxxxxxxx>
