On Wed, Sep 06, 2017 at 07:43:05AM -0400, Brian Foster wrote: > That said, while the implementation improvement makes sense, I'm still > not necessarily convinced that this has a place in the upstream realtime > feature. I'll grant you that I'm not terribly familiar with the > historical realtime use case.. Dave, do you see value in such a > heuristic as it relates to the realtime feature (not this tiering > setup)? Is there necessarily a mapping between a large file size and a > file that should be tagged realtime? I don't see it much differently to the inode32 allocator policy. That separates metadata from data based on the type of allocation that is going to take place. inode32 decides on the AG for the inode data on the first data allocation (via the ag rotor), so there's already precedence for this sort of "locality selection at initial allocation" policy in the XFS allocation algorithms. Some workloads run really well on inode32 because the metadata ends up tightly packed and you can keep lots of disks busy with a dm concat because data IO is effectively distributed over all AGs. We've never done that automatically with the rt device before, but if it allows hybrid setups to be constructed easily then I can see it being beneficial to those same sorts of worklaods.... And, FWIW, auto rtdev selection might also work quite nicely with write once large file workloads (i.e. archives) on SMR drives - data device for the PMR region for metadata and small or temporary files, rt device w/ appropriate extent size for larges files in the SMR region... > E.g., I suppose somebody who is > using traditional realtime (i.e., no SSD) and has a mix of legitimate > realtime (streaming media) files and large sparse virt disk images or > something of that nature would need to know to not use this feature > (i.e., this requires documentation)..? It wouldn't be enabled by default. We can't break existing rt device setups, so I don't see any issue here. And, well, someone mixing realtime and sparse virt in the same filesystem and storage isn't going to get reliable realtime response. i.e. nobody in their right mind mixes realtime streaming workloads with anything else - it's always dedicated hardware for RT.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
