3 ms·
You'll just adding more long stats and pushing more metadata into cache if you add another directory level. You should look probably into a Haystack-like appr
by termie 17y ago
You'll just adding more long stats and pushing more metadata into cache if you add another directory level. You should look probably into a Haystack-like approach where you have a single file blob (or several large blobs) and then maintain an index into the offsets.
- ajross 17y agoIsn't that feature (managing storage so you don't have to) precisely the reason for using a "filesystem" in the first place? Your suggestion is isomorphic to telling the poster to chuck the filesystem and just write to the block device directly. It's almost certainly not a sane real-world option.
- apgwoz 17y agoIsn't what both of you are describing a filesystem in itself?
- termie 17y agoThis guy is already @366M objects and growing... halving or quartering the number for file i/os in a large system like this has real, observable and proven benefit. It's definitely not for the meek, but adding another directory (and adding an additional metadata lookup) is not the way to go. When you get to more than a billion objects all requiring 5+ metadata entries that need to get walked on every request, you might see it differently.
- ajross 17y agoNo, that's silly. You're not changing the number of I/O operations at all. You're simply moving the location in code where they are done from the kernel's filesystem to the applications's userspace. There's no reason to expect either to be faster by anything other than a constant factor.