LWN: Comments on "Time to merge GFS?"

How things come back from the past ...

addw — Sun, 14 Aug 2005 18:36:52 +0000

I remember the sequent and pyramid boxes of a decade or two back ... these machines were multi universe ones: processes could see either System V or BSD system calls and file system layout - depending on the universe that the process was in.

One 'feature' was a conditional symbolic link ... what it pointed to depended on the universe setting.

Sounds like a nice idea, but it was vile. I hated it.

context-dependent symlink

giraffedata — Fri, 12 Aug 2005 22:05:20 +0000

The objections to context-dependent links include ... the fact that they are specific to one filesystem [type].

If that's a valid objection, we need to get rid of the "followlink" inode operation. Its existence specifically says that the meaning of symbolic link contents is filesystem-type-dependent. The common path walk code could as easily do a "readlink" inode operation and interpret the contents as a path itself. So someone wanted it that way.

In the continual battle between filesystem type consistency and filesystem type diversity, the VFS interface is what defines the front.

Time to merge GFS?

iabervon — Thu, 11 Aug 2005 17:49:15 +0000

It gets a bit tricky if you've got a couple hundred symlinks bin -> @os/bin in different directories. The point with using symlinks for it is that regular users can create these links without suid programs when they want portions of their home directories to behave differently on different hosts.

Of course, this should probably be an aspect of namespaces, such that it applies to everything, but only if you've enabled it.

Time to merge GFS?

hpp — Thu, 11 Aug 2005 12:28:45 +0000

The Andrew File System (AFS) has a similar mechanism where a pathname component named @sys instead goes to your hardware platform. On my box here at work (we're a big AFS shop),

.../@sys/bin/mozilla

goes to

.../ia32.linux.2.4.glibc.2.3/bin/mozilla

and we use this to store binaries for multiple architectures side by side.

This has existed in AFS forever, and is supported in Linux. I'm not sure why this is not a problem in AFS but would be a problem for GFS.

Could this be the location where the magic @sys token gets expanded? In AFS, this is all done on the client side, so the fileserver is not aware of the magic / trickery in the lookup.

Time to merge GFS?

penberg — Thu, 11 Aug 2005 11:33:38 +0000

> The problem has already been solved. Please, no more bloat!.

It has already been taken out of GFS2 code by the developers.

Time to merge GFS?

dw — Thu, 11 Aug 2005 10:25:42 +0000

As pointed out in the article, this symlink content scanning is completely unnecessary bloat, whos functionality can be accomplished through other functionality already available in the kernel.

@hostname  Boot-time symlink or bind mount
@mach      Boot-time symlink or bind mount
@os        Boot-time symlink or bind mount
@uid       Private namespaces

I built a cluster a few years back that booted 36 completely diskless nodes off a single shared readonly NFS root. This involved about 5 lines of bindmounting and tmpfs, along with commenting out fsck checks and suchnot. That cluster is still operational, sitting in a room about 10 yards away. :)

The problem has already been solved. Please, no more bloat!