Hi,
On Thu, Oct 26, 2000 at 09:26:22PM -0700, Hans Reiser wrote:
> You are making extended attributes different from files in more than name. This is
>deeply and
> fundamentally wrong.
ACLs, MACs etc _are_ fundamentally different. They don't have a byte
stream structure. They are more like datagrams than tcp streams, to
take a networking analogy. There are plenty of file attributes which
are not streamlike: mode, owner etc. This is nothing new.
The API here is designed *exclusively* for non-streamlike attributes.
If your filesystem can actually implement stream-like attributes, then
you can also use the filesystem namespace to access those attributes
--- that's great.
> > I am *not* going to implement database-style transactions just for
> > something which is basically an extended chmod()! It is also quite
>
> then don't misfeature atomicity in! If you can't do it right, don't code it into
>VFS so that we all
> get stuck with it!
Huh? ACLs *must* be updated atomically. You have no choice.
Anything else is a security hole. It's not optional.
> > impossible to implement arbitrary transactions over filesystems such
> > as NFS, but we still need ACL APIs for that.
>
> So don't make atomic a filesystem that doesn't support atomicity. Why do you want
>to do that? What
> is even crazier is that you blame me for this requirement of yours which is
>supposedly a requirement
> of mine. If it doesn't support atomicity it ignores the atomicity specification by
>the user, if it
> requires atomicity it imposes it on the user, if it is well designed it does as
>asked, what is the
> problem?
Calm down --- who said anything about blame???!!!
I already said that "transactional" != "atomic". "transactional"
means updated atomically on disk. "atomic" in memory is a separate
issue, and ACLs only need that. Atomic in memory is much easier ---
we only need a lock around the update, we don't need any fancy on-disk
write ordering tricks.
If you mean transactional on disk, then we agree --- if the filesystem
can support it, that's great; if not, no big loss, we weren't
promising anything anyway.
> You have some misdesigned filesystems you want to support by forcing all the rest of
>the filesystems
> to be misdesigned. Make misdesign optional not mandatory. That means don't give us
>a single way of
> doing things that combines several different features in a non-orthogonalized way
>that forces us to
> take all features when we only want one of them.
I agree --- that's why we need an ACL API which doesn't require the
use of a named-file byte-stream. The two pieces of functionality are
orthogonal. I don't want to get in the way of anybody who wants to
implement named streams, but there are a ton of existing ACL
implementations which don't work that way and we need to support them.
Hans, I am *NOT* suggesting that reiserfs must implement all its
attributes in any specific way. However, there is most definitely a
need for some form of fairly standard way to access specific
attributes such as ACLs and DMAPI attributes.
Cheers,
Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
