Re: reiser4 plugins

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hubert Chan wrote:
On Tue, 28 Jun 2005 15:22:55 -0500, David Masover <[email protected]> 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux