A case for variant symlinks [LWN.net]

A case for variant symlinks

Posted Mar 30, 2016 2:02 UTC (Wed) by Cyberax (✭ supporter ✭, #52523)
In reply to: A case for variant symlinks by viro
Parent article: A case for variant symlinks

> So you need to be able to locate all those stacks containing given dentry at any point *and* atomically rewrite all of them, possibly extending or shrinking the damn things, and that is even before you start considering the games you need to play with dentry refcounts.
Well, I didn't say it's easy or efficient.

I personally wouldn't mind hardlinked directories (I can see where they can be handy), but then I also want O_PONIES.

> You just need to verify that you do not attempt to make a node its own descendent, which is trivial if you keep track of the (only) chain of ancestors.
But that holds just as well for the multi-hardlinked directories. To avoid cycles the FS has to uphold the invariant "no links from a directory to any of its parent directories". It doesn't require full tree scanning.

If loops _are_ allowed then I'm pretty sure the filesystem will require a tracing garbage collector.

to post comments

A case for variant symlinks

Posted Mar 30, 2016 3:14 UTC (Wed) by viro (subscriber, #7872) [Link] (1 responses)

... except that now you need to maintain the list of all parents through all operations. What's worse, you can't just stop at direct parents - you need traverse all chains of ancestors, however long they might be. With the unique chain to root you already have all of that in RAM - you either get them from pathname resolution, or you've started with fhandles and their decoding includes traversing the chain of ancestors until the damn thing is connected to the root. With multiple links you could very well have never seen the majority of those ancestors, which means that loop detection turns into massive IO. Now add the fact that you need to block all rename() (and link() to directories, and rmdir()) for the duration of that check, and it becomes _very_ unattractive. Locking is also less than pleasant. Once you add that to the costs of maintaining the crap attached to struct file, well...

It's not impossible that somebody would eventually come up with a decent way of doing that stuff. I've never been able to. Neither had *BSD folks. And Thompson, Pike et.al. flat-out decided that all that crap was just too much headache to bother with - even though they started their list of the bad ideas not to duplicate with cross-directory renames, overwriting renames, symlinks and fchdir. On very different VFS architectures, including the one designed pretty much from scratch, with freedom to drop the syscalls considered to be misfeatures. Which is something the rest of us couldn't afford - not without breaking arseloads of userland code.

Again, maybe there is a decent way of doing that just waiting for somebody to invent it. I would love to read it through and try to poke holes in it - got to be interesting. But until somebody does come up with something that survives peer review... Filesystem with multiple hardlinks to directories is a Bloody Bad Idea(tm). Sorry.

A case for variant symlinks

Posted Mar 30, 2016 3:25 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

I have a feeling that it might be possible to devise a way for the "happy case" (no hardlinks in any parent) to be about as fast as the current case. But once hardlinks start appearing, it'll devolve rapidly (a nice DoS right there).

And I feel that even alternative VFS designs are not going to help unless they introduce a full-scale garbage collector. Which might not even be such a bad idea once we switch to non-volatile memory.