Re: reiser4 plugins

David Masover
2005-07-01T09:00:32Z

Hubert Chan wrote:
> On Tue, 28 Jun 2005 15:22:55 -0500, David Masover <ninja@slaphack.com> 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 "..."