https://bugzilla.kernel.org/show_bug.cgi?id=107301 --- Comment #20 from Theodore Tso <tytso@xxxxxxx> --- Apologies for not responding right away. I'm currently on vacation. So this also means that if someone sends me a patch right away, I'm not likely to have time to look at it for a week or two. As far as trying to make mbcache more scalable, this would be great, but I suspect it's not going to be very easy because it requires a global data structure, which is fundamentally hard to scale. I can imagine some schemes that sacrifice some of mbcache's ability to spot duplicate xattr sets --- for example, you could just use a trylock, and if there is lock contention just give up on detecting duplicate xattrs. Or maybe we could use some hueristics based on the xattr type/key to decide whether using mbcache is likely to be successful. So if we know that Posix ACL's are very likely to be shared, and ceph xattrs are very unlikely to be shared, this could be used to decide whether or not to use mbcache automatically, without requiring a mount option. Even better would be one where for unknonw xattr type/key combinations, we use some learning algorithm which determines after using mbcache for N instances of that xattr, if the percentage of cache hits is too low, we stop using mbcache for that type/key combination. -- You are receiving this mail because: You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
