lkml.org 
[lkml]   [2005]   [Aug]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [Linux-cluster] Re: [PATCH 00/14] GFS
Date
On Aug 10, 2005, at 09:26:26, AJ Lewis wrote:
> 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 directory hierarchy 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.
>
> I'm just thinking of a 100-node cluster that has different mounts
> on different
> nodes, and trying to update the bind mounts in a sane and efficient
> manner
> without clobbering the various mount setups. Ouch.

How about something like the following:
cpslink() => Create a Context Dependent Symlink
readcpslink() => Return the Context Dependent path data
readlink() => Return the path of the Context Dependent
Symlink as it
would be evaluated in the current context,
basically as a
normal symlink.
lstat() => Return information on the Context Dependent
Symlink in
the same format as a regular symlink.
unlink() => Delete the Context Dependent Symlink.

You would need an extra userspace tool that understands cpslink/
readcpslink to
create and get information on the links for now, but ls and ln could
eventually
be updated, and until then the would provide sane behavior. Perhaps
this
should be extended into a new API for some of the strange things several
filesystems want to do in the VFS:
extlink() => Create an extended filesystem link (with type
specified)
readextlink() => Return the path (and type) for the link

The filesystem could define how each type of link acts with respect
to other
syscalls. OpenAFS could use extlink() instead of their symlink magic
for
adjusting the AFS volume hierarchy. The new in-kernel AFS client
could use it
in similar fashion (It has no method to adjust hierarchy, because
it's still
read-only). GFS could use it for their Context Dependent Symlinks.
Since it
would pass the type in as well, it would be possible to use it for
different
kinds of links on the same filesystem.

Cheers,
Kyle Moffett

--
Simple things should be simple and complex things should be possible
-- Alan Kay



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-08-10 17:45    [W:0.076 / U:0.972 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site