>>>>> "Andreas" == Andreas Dilger <adilger@xxxxxxxxx> writes: Andreas> It doesn't cost anything to reserve the first 32 values for Andreas> filesystem metadata, and they can be aggregated more or less Andreas> depending on the hardware capabilities. Even if current Andreas> devices only support 4 or 8 streams, I'm sure that this will Andreas> improve in the future, so it doesn't make sense to limit Andreas> ourselves based on the very first devices on the market. I am not against reserving parts of the namespace. As long as the anticipation is that those 32 values in practice will be consolidated into probably 2 (journal and metadata) in a static fashion. Because, as I said, there are performance and serialization issues wrt. closing and opening streams. So I don't think doing it in the hotpath is going to fly. Andreas> Also, this opens up interesting possibilities for blktrace, DM Andreas> layers like dm-thinp, bcache, etc. that are currently lacking Andreas> any kind of data on how they should allocate blocks. Ted Andreas> described the contortions he does to map from block offsets in Andreas> blktrace to filesystem metadata using debugfs output and Andreas> scripts, and not everyone is as knowledgeable about filesystem Andreas> internals as he is, but still wants to be able to diagnose Andreas> filesystem IO latency issues. I am a big proponent of I/O tagging. We use it extensively in various products and it works beautifully. That's why I would like to see the storage standards being able to support it. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
