Re: reiser4 plugins

[David Masover]

Hubert Chan wrote:
> On Tue, 28 Jun 2005 15:22:55 -0500, David Masover <ninja@xxxxxxxxxxxx> said:
>
>
> > Come to think of it, that changes the proposal a bit.  You need a
> > different way to access the meta-dir for files than for directories,
> > if we're going to support /meta/vfs.  No biggie:
>
>
> > /meta/vfs/file/home/bob/sue.mpg/acl
> > /meta/vfs/dir/home/bob/acl
>
>
> What if /home has an extended attribute named bob?  Then is
> /meta/vfs/dir/home/bob a file or a directory?

Ah, you caught it.  I knew it didn't feel right.  So /meta/vfs/file and 
/meta/vfs/dir are worthless.

Ok, there has to be a delimiter of some kind.  That, or there has to be 
a way we can pick up front how deep we're going.  Or, someone else has 
to come up with a better idea.  Or, start out with the assumption that 
we're talking about metadata, instead of the other way around.

I don't like delimiters because the way we usually deal with these is 
escaping them when we need to.  For instance, if I want to actually pass 
a literal " character to some command, I can wrap it in ' characters or 
add a \ to the front of it.

But we're expecting this to be simpler than that.  A program trying to 
access the metas for some file shouldn't have to worry about escaping.

Last time we tried to come up with a delimiter, we ended up with ... and 
..metas as possible candidates, and ..metas was in the source.  As 
unlikely as it is to hit either of those, I still don't like them.

Programs would mostly use the inodes anyway, and users would mostly use 
the /meta/vfs interface, but it's still not pretty.

But, the only alternative I can think of now is /meta/vfs/2/home/bob is 
a file and /meta/vfs/3/home/bob is a directory.  That's not something we 
want our users to have to do, especially considering we want to be able 
to have metadata of metadata.

That, or we can try something like:

/meta/vfs/#/home/#/bob	is a directory
/home/vfs/#/home/bob	is a file

where we add a delimiter to the /meta dir which identifies where each 
directory begins, not each set of metadata.  To clarify a bit:

$ ls /meta/vfs/
mime
permissions
acls
#
[snip]

$ ls /meta/vfs/#/
proc
sys
tmp
etc
home
[snip]

$ ls /meta/vfs/#/home
mime
permissions
acls
#
[snip]

$ ls /meta/vfs/#/home/#/
bob
billy
hank
sue
[snip]

This is pretty annoying for the user, though, because it's more verbose. 
 But, at least this way, we can guarentee that no one will kill our 
delimiter, because it exists in a new namespace we're creating anyway. 
That is, if we have to, the old xattrs stuff can go in its own folder, 
and so even if some app currently depends on a '#' app, it won't kill 
our delimiter.

Now, if only there was an easier delimiter to type...


Ok, since file-as-dir was going to do this anyway, I think the way to go 
is probably the original '...' delimiter.  It's safer, because it stays 
in /meta, but it's dangerous, because someone might actually try to 
create a '...' file on an existing system.  But, I think we can live 
with introducing a delimiter, more than we can live with uglifying the 
/meta/vfs interface, especially because "touch ..." wouldn't make the 
system blow up, you just couldn't easily get metadata for "..."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/