DragonFly BSD
DragonFly kernel List (threaded) for 2011-07
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

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

From: Justin Sherrill <justin@xxxxxxxxxxxxxxxxxx>
Date: Sun, 3 Jul 2011 09:50:23 -0400

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

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]