Re: HAMMER2 design in progress - 1-2 year time frame

[Justin Sherrill <justin@xxxxxxxxxxxxxxxxxx>]

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:

http://git.661346.n2.nabble.com/PATCH-6-6-Always-provide-a-fallback-when-hardlinks-fail-td729065.html

And here's some vague discussion about it:

http://www.freelists.org/post/haiku-development/BFSs-Lack-Of-Support-For-link-hard-links,11

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@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.
>
>                                                -Matt
>