HAMMER2 design in progress - 1-2 year time frame
justin at shiningsilence.com
Sun Jul 3 06:52:22 PDT 2011
This is mostly just to note it for later, but: BFS, used in BeOS/Haiku
does not support hardlinks either, so this isn't the first time this
problem has happened. It would cause problems in git, for instance,
if I read this correctly:
And here's some vague discussion about it:
We have the minor disadvantage that just because a system is DragonFly
doesn't mean that we won't support hardlinks (i.e. a hammer1 or ufs
filesystem), so it may be difficult for 3rd-party software to tell
what the correct behavior is.
It would be interesting to see if the mechanisms for deduplication and
hardlinks could be brought together to solve this; that's a vague
suggestion rather than a feasible plan, though.
On Sun, Jul 3, 2011 at 2:40 AM, Matthew Dillon
<dillon at apollo.backplane.com> wrote:
> Well, the problem with hardlinks in HAMMER2 is a bit different than
> tagging files and directories with additional meta-data.
> Meta-data is actually very easy to do from a cache coherency standpoint,
> but difficult to reliably copy and archive (particularly across
> filesystem types).
> Hardlinks create multiple synchronization/coherency paths from each link
> (to the same file) all the way back to the root. In a clustered
> filesystem with fine-grained cache coherency on the DIRECTORY TOPOLOGY,
> verses just the file inode, this can wind up being O(n log n) in overhead,
> approximately, for each system call operating on the file (where (n) is
> the number of hard links). Performance suffers badly and the cache
> coherency algorithms also wind up being far more complex... too complex
> to be desireable, really.
> I'll continue to think about how at least a small number of hardlinks
> could be implemented without turning already complex cluster algorithms
> into a disaster zone. So far I'm drawing a blank.
More information about the Kernel