lkml.org 
[lkml]   [2005]   [Jul]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: reiser4 plugins
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/

\
 
 \ /
  Last update: 2005-07-06 21:33    [W:0.302 / U:50.920 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site