On Wed, 25 Oct 2000, Stephen C. Tweedie wrote:
> Hi,
>
> On Wed, Oct 25, 2000 at 03:03:59AM +0200, Andreas Gruenbacher wrote:
> > On Tue, 24 Oct 2000, Stephen C. Tweedie wrote:
> >
> > > But that API is insufficient for EAs. We already have filesystems
> > > which implement independent system and user namespaces: adopting a
> > > random new convention like "system attributes start with '$'" is
> > > incompatible with those, so we can't ever mount an existing XFS (for
> > > example) filesystem and access its EAs cleanly.
> >
> > Point taken. I therefore propose to prefix extended user attributes with
> > another character (say, "."), or alternatively, to use a string prefix,
> > like "user.mime_type", "system.acl", etc. That should get us rid of such
> > compatibility issues.
>
> So how do we deal with an existing filesystem which allows user
> attributes to be prefixed with "." or "$"? Or which allows arbitrary
> other prefixes? Or which allows "." in the middle of attribute names?
If all EAs always have prefixes, that's no real problem, though it gets a
bit ugly. For XFS, one possible mapping would be "user" and "root"
namespaces as far as the filesystem is concerned. A user attribute with a
weird name such as "&%/" would then probably become "user.&%/" (if that is
permitted on XFS, I don't know). Another possibility would be to use some
sort of encoding for special characters in EA names.
A different separator ("/" instead of "."?) might make sense. Not sure.
> Or how do we deal with filesystems whose namespace for attributes is a
> binary integer? (Yes, they exist.)
I think it is a really big advantage to keep the attribute names human
readable. So I would tend to encode those in some way, like the ninetiest
user EA as user.90 or user.5a (hex). Supporting binary EA names wouldn't
be difficult, but textual seems superior to me. Also with binary EA names,
you'd have to watch out for byte ordering issues and such to keep the
interface portable, which isn't very funny.
> Also, your API doesn't let us set multiple EAs at once, or to do an
> atomic set-and-get.
True. Multiple-updates was something I explicitly tried not to get into
the API. It makes things much more complicated (and prone to bugs). I
really don't see the need for that. If you think this is an essential
feature, a good example might convince me.
I now see your point about set-and-get. And I also agree some mechanism
like that is essential, but get-and-set doesn't appear to work. Consider
this:
# process 1 process 2 comment
- --------- --------- -------
1 get -> v process 1 reads an EA
and then gets interrupted.
2 get -> v process 2 reads an EA,
3 get_set(w) -> v and succeeds in updating it.
4 get_set(x) - > w process 1 then tries to
update the EA, and realizes
the EA has changed.
5 get_set(y) -> w process 1 retries (based on
the new value w), and now
succeeds.
Commentary
----------
(1) Process 1 reads an EA and then gets interrupted.
(2+3) Process 2 reads an EA, and succeeds in updating it.
(4) Process 1 then tries to update the EA, and realizes the EA
value has changed.
(5) Process 1 retries (based on the new value w), and now succeeds.
A crash of process 1 in between 4 and 5 leaves the system in an
inconsistent state. What's more, the inconsistent value is also exposed to
other processes that read the EA between steps 4 and 5.
A different operation, set_if_equal(old_value, new_value) would probably
work.
Another (perhaps simpler) approach might be to use versioning, using the
operations get_with_version() -> (value, version) and
set_if_current(new_value, old_version).
That interface might be impossible to implement over existing network
protocols. But then, set_if_equal() might not be supported either, so
there wouldn't be a way to make it work over those protocols anyway.
> Thirdly, it doesn't deal with extension --- what if I want to add a
> new type of attribute? Say, MAC labels or file flags (eg. ext2
> "chattr" flags)?
What's wrong with system.mac, inode.immutable, etc.? (Oh yes, here we have
a case for per-inode EAs.) Another possibility would be to mirror multiple
ext2 attributes in a single EA (say, inode.flags).
> With the fsetattr() API, you can define new attribute families very
> easily without losing the advantages of a properly typed API.
The single-namespace interface isn't fundamentally different. What you
keep in the attribute family parameter I keep in the prefix. I somewhat
prefer the prefix approach as it seems slightly simpler to me from the
point of users.
> [...]
>
> Either way, the point stands -- building APIs on assumptions about
> implementation details (in this case, that ACLs are built on top of
> EAs) is a bad thing.
True enough.
The interface I proposed doesn't enforce the implementation though (I
guess I was unclear about this). Filesystems may want to implement
specific attributes differently. It isn't too hard to provide a mapping
from say, ext2 attributes (immutable and such) to one or more extended
attributes.
The system call interface and filesystem interface would be extended
attributes, but the filesystem is free to implement them differently (or
not at all).
One other thing my interface explicitly does not support is updating only
part of an EA. That _could_ be implemented with the versioning interface
above. I would still consider allowing that a very bad idea. It would
severely complicate the implementation, and also the interface. I would
assume very hard-to-detect bugs in such an implementation would be quite
likely.
Cheers,
Andreas.
------------------------------------------------------------------------
Andreas Gruenbacher, [EMAIL PROTECTED]
Contact information: http://www.bestbits.at/~ag/
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
