Re: reiser4 plugins

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

 



Hans Reiser wrote:
It was always the expectation that users would want to have one
mountpoint with the files having metafiles as files, and another with
the same files but strictly posix, and then their apps can use whichever
they have the power to understand.

It was never in the early betas I tried :(

I'm proposing (or re-proposing) that the /meta mountpoint be strictly for accessing meta-files, with no intention of eventually using this by default. Furthermore, /meta should follow POSIX anyway, mostly -- no file-as-dir there, either, although you still wouldn't want to use tar on it.

With only a few patches, using /meta could be almost as convenient as using file/..metas/foo, and it completely kills the file-as-directory flamewar -- everybody's happy.

Or so I thought. It seems that the people arguing for file-as-directory are ignoring /meta, and the people arguing against it are arguing against all meta-files, saying that the good things about meta-files don't justify the risks of file-as-dir. Only once did I see someone bring up /meta.

I don't like the idea of having /meta have file-as-dir and everything as we originally wanted, because then we've duplicated the interface. To read the *contents* of /foo, I can either cat /foo or cat /meta/foo. I'd hate to have the POSIX mountpoint still lying around if no one's using it, even more than I hate the idea of "foo" being in two places for no good reason.

Is there a technical (performance?) reason that my approach is wrong? (metas go in /meta, files go in /, and everything feels POSIX-y)

Hans

David Masover wrote:


Hubert Chan wrote:


On Wed, 29 Jun 2005 17:34:41 -0400, Ross Biro <[email protected]>
said:



I'm confused.  Can someone on one of these lists enlighten me?



How is directories as files logically any different than putting all
data into .data files and making all files directories (yes you would
need some sort of special handling for files that were really called
.data).  Then it's just a matter of deciding what happens when you
call open and stat on one of these files?



Logically, I don't think there is a difference. A filesystem that
doesn't support file-as-dir could implement the same functionality that
way. [1]  In fact, that's essentially what MacOS X/NeXTSTEP does with
its
bundle format -- it's just a regular directory with regular files
inside.


I, personally, would hate it if everything in my /bin suddenly became
a directory, mainly because everything would stop working.  Is that
the kind of thing you're suggesting?

I'm a little confused about the .data idea, I guess.


But we could have a whole new set of system calls that treat things as
magic, and if files as directories is as cool as many people think,
apps will start using the new api.  If not, they won't and the new api
can be deprecated.



File-as-dir doesn't require new system calls (that I know of), which is
the whole point of the idea.  Existing programs can edit the strange new
attributes without being modified.


That is indeed the point, but scroll down.


The main thing blocking file-as-dir is that there are some
locking(IIRC?) issues.  And, of course, some people wouldn't want it to
be merged into the mainline kernel.  (Of course, the latter doesn't
prevent Namesys from maintaining their own patches for people to play
around with.)


What's the locking issue?  I think that was more about transactions...

[...]


People like Horst (and probably others, who are less vocal), I think,
don't think that it's even worth trying it out because they don't see
any major advantages.  Or at least they think that the potential
negatives outweigh the potential positives.  I respect that they have
different opinions, but I of course disagree and attempt to convince
them otherwise.


Did the /meta (metafs) idea get killed while I was out?  Using that
approach, your potential negatives are that apps which crawl the
entire FS tree, starting at /, with hardcoded apps for /proc and /sys,
are now broken -- but then, /sys already broke them once, so I don't
particularly care if we break them again.

Potential positives?  I think even just because we like the idea is
enough, because it doesn't break anything and doesn't really affect
anyone who doesn't use it.

Maybe there are coding standards, but I think others are working that
out now.





-
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