Re: reiser4 plugins

[Hans Reiser <reiser@namesys.com>]

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.

Hans

David Masover wrote:

> Hubert Chan wrote:
>
>> On Wed, 29 Jun 2005 17:34:41 -0400, Ross Biro <ross.biro@gmail.com>
>> 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 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/