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

[Linux-cluster] Re: [PATCH 00/14] GFS



On Wed, Aug 10, 2005 at 12:11:10PM +0100, Christoph Hellwig wrote:
> On Wed, Aug 10, 2005 at 01:09:17PM +0200, Lars Marowsky-Bree wrote:
> > 
> > So for every directoy hiearchy on a shared filesystem, each user needs
> > to have the complete list of bindmounts needed, and automatically resync
> > that across all nodes when a new one is added or removed? And then have
> > that executed by root, because a regular user can't?
> 
> Do it in an initscripts and let users simply not do it, they shouldn't
> even know what kind of filesystem they are on.

Christoph,
	Users know.  They want to know.  They want to install git on a
shared filesystem, and have it Just Work no matter what architecture
they're on ({arch} context symlink).
	I've yet to see a sane way to replace symlinks with bind mounts
for anything but the most trivial of usages.

1) You can't make them as non-root
2) It's not stored in the filesystem, so permanence is separate.  Other
   nodes and namespaces don't see them automatically if you want it.
   These both violate KISS and PoLS.
3) You pollute the output of "mount", and when you have as many bind
   mounts as you might have symlinks, that's a ton of output you didn't
   want to see when you were wondering what disks are mounted.
4) When I'm looking at a file, ls -l doesn't tell me what I'm really
   looking at.  With symlinks it does.  In some circumstances, that's a
   good thing.  For most symlink-like uses it is not.  The two uses
   (security and "symlink-like") are both valid approaches, and one
   should not preclude the other.

	Now, (3) can easily be fixed with an option.  (4) can probably
be massaged the same way.  But (1) and (2) can't be, and that needs
fixing before this is even viable to most real users.
	CDSL, or whatever you call it, exists in most can-be-shared
filesystems for a reason.  On AFS and DFS, it was @foo.
/.../thisdcecell/foo/@sys/bin/git-ls-tree would be
/.../thisdcecell/foo/linux-i386/bin/git-ls-tree on my machine.  I'd just
put the @sys path in my PATH, and never worry whether I was on x86, ppc,
or s390.  I don't know how GFS/GFS2 do theirs, but OCFS2 copied straight
from VMS clustering, where they used it as well.  They seem to have set
the standard on the topic of clustering.  It would be
/usr/{arch}/bin/git-ls-tree -> /usr/i386/bin/git-ls-tree or whatever.
	If you can't do this as a user, it's irrelevant to you.  Major
installations, where the person installing the application never gets
root, would expect it to work easily and nicely.  Bind mounts, as of
now, do not.

Joel

-- 

"Here's something to think about:  How come you never see a headline
 like ``Psychic Wins Lottery''?"
	- Jay Leno

Joel Becker
Senior Member of Technical Staff
Oracle
E-mail: joel becker oracle com
Phone: (650) 506-8127


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