lkml.org 
[lkml]   [2005]   [Jul]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: reiser4 plugins
Stefan Smietanowski wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>>Ok, still haven't heard much discussion of metafs vs file-as-directory,
>>but it seems like it'd be easier in metafs.
>
>
> Why not implement it inside the directory containg the file ?
>
> Ie the metadata for /home/stesmi/foo is in /home/stesmi/.meta/foo
>
> This should be suit both camps I'd think?

You still need to figure out the parent of "foo", which isn't
necessarily easy, especially considering that even if we store a link to
the parent, it will be inside the metadata. Then you have a
chicken-and-egg situation.

Both camps seem to want to allow easy access to the metadata of a file,
whether we're given that file as an inode or as a pathname. That's why
I suggested /meta/vfs and /meta/inode -- sometimes I want to look up a
file by name, and sometimes by inode, but either way, I should be able
to get its metadata.

> I mean, editing something is easy and you don't have to "know" how
> to navigate /meta

But then you have to "know" how to navigate .meta, and more importantly,
how to find .meta

> and you don't have the clash of files vs metadata
> (is /meta/vfs/home/stesmi/foo a file or an attribute called foo of
> the dir stesmi ?).

So, how do I get metadata of a directory? If the metadata for /home/me
is in /home/.meta/me, and the metadata for /home is in /.meta/home, then
where is the metadata for / ?

> /home/stesmi/foo <- dir
> /home/stesmi/.meta/foo <- "dir" containing all metadata
> /home/stesmi/.meta/foo/attrib <- some attribute called attrib
> /home/stesmi/foo/bar <- file
> /home/stesmi/foo/.meta/bar <- "dir" containg all metadata
> /home/stesmi/foo/.meta/bar/attrib <- some attribute called attrib

[...]

> If this has already been taken up, I must've missed it.

It looks a lot like how I suggested we resolve the ambiguity within
/meta/vfs, only I called it '...' instead of '.meta'.

Either way, the major challenge to this method is not so much whether
it'd work, but how to choose a suitable delimiter? The delimiter must
be standard if we're going to have apps develop for it, and it must not
be used in the name of any existing file or directory.

I had a long essay here on how '.meta' breaks every recursive operation
on directories (rm -rf, tar, mkisofs), but I deleted it when I
remembered that I played around with the alpha/beta reiser4 which had a
'metas' dir that did the same thing, but was hidden from the normal
directory listing. 'cd metas' worked, 'ls metas' worked, but 'ls'
showed no directory called 'metas'.

I don't *think* there are any apps that will break if you tell them to
open a path that doesn't exist in a directory listing. That is, typing
'vim /home/metas/acl' should always let me edit the acl on /home, and
vim should never complain about how /home/metas doesn't show up in
/home. A program would have to be pretty retarded to fail on something
like that.

But, we have to support some pretty retarded programs. That is why I
like /meta -- the default view is a completely POSIX-compliant tree that
works with tar, and even the /meta view is POSIX-compliant, even if it'd
be a bad idea to tar it. Then we don't have to worry at all about
stupid programs.

How much should we be worrying about this particular brand of stupidity?
And what's a good delimiter?


--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.8.12/46 - Release Date: 7/11/2005

-
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-12 02:13    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site