Re: reiser4 plugins

[David Masover <ninja@slaphack.com>]

Hans Reiser wrote:
> If we also add to this the restriction that once you create the file
> part of a file-directory, you can never hardlink to a child of it, it
> should then all work, yes?
>
> So, /filename/..../owner should be able to avoid colliding with any
> common names by virtue of the '....', and not letting any filedir
> (file-directory) have children with links to them should also work.  The
> one thing that seems inelegant is that when you create the file part of
> a filedir, you must check all its children for hardlinks and fail if
> they exist, and you must flag all its directory children so that the
> plugins for them will disallow hardlinks to their children from that
> point onward.  Still, seems workable....

Ok, still haven't heard much discussion of metafs vs file-as-directory, 
but it seems like it'd be easier in metafs.

Basically, we are entirely POSIX compliant outside of metafs, so that 
/filename is a file and may be hardlinked, and /directory/ is a 
directory and may not.  No problems yet.

Inside /meta/inode, we have no problems yet because any hardlinks 
created outside /meta won't even show up as hardlinks here, so we don't 
get hardlinked directories.

Inside /meta/vfs, where we can find the metadata of '/filename' under 
'/meta/vfs/filename/...', we have what looks like a problem -- we may 
have hardlinks created outside metafs, which will show up as two 
directories inside metafs, so those directories are hardlinks.

I don't think that's such a problem, since we won't allow users to 
change anything in /meta/vfs except when it's inside metadata, such as 
'/meta/vfs/some/where/...'.

Thus, it's impossible to create a hardlink to a directory unless we do 
it *outside* metafs, as a hardlink to a file.

Now, the question I asked is, what if we want hardlinks *inside* metafs, 
*inside* the metadata for a given file, and would we ever want such a 
thing?  Because we can avoid the whole problem if we just disallow any 
sys_link calls inside metafs.

Of course, sometimes we want to have a chunk of metadata that appears 
*exactly* as if it were a normal, POSIX-compliant directory tree, such 
as the contents of a tarball or a zipfile.  In that case, we might want 
to have the "zip" plugin allow hardlinks inside 
"/meta/file.zip/.../contents" -- the only restriction is that any 
hardlink made to a file inside 'contents' must be made to another file 
inside 'contents'.

> Hans Reiser wrote:
>
>
> > David Masover wrote:
> >
> >
> >
> >
> > > Now, can anyone think of a situation where we want user-created
> > > hardlinks inside metadata?  More importantly, what do we do about it?
> > >
> > >
> > >   
> >
> > I think the equivalent of symlinks would be good enough to get by on for
> > now for most linking of metafiles.  Maybe some years from now somebody
> > can fault me for saying this and write a patch to fix it to be better,
> > at which point I will be happy to concede the point.
> >
> > So the basic principal here is, one can have hardlinks to directories
> > without cycles provided that one does not allow any child of the
> > directory to have a hardlink.  The question is, how cleanly can that
> > relaxed restriction be coded?
> >
> > Hans

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