On Tue, Oct 24, 2000 at 01:46:49PM +0100, Stephen C. Tweedie wrote:
> On Tue, Oct 24, 2000 at 02:03:51PM +0200, Christoph Hellwig wrote:
>
> > IMHO the EA stuff should be mostly used as backing-store for other APIs.
>
> Agreed, partially.
>
> For things like DMAPI (XDSM), we have a high-level API which wants to
> store arbitrary information in the filesystem. The kernel doesn't
> have to parse that info --- it just makes it available to the upper
> API. That's an ideal candidate for ATR_SYSTEM extended attributes.
Actually that's only partially true, the XDSM needs both to store opaque
data and data that must be parsed in the kernel (e.g. managed regions).
> If the underlying implementation in the filesystem wants to use its
> normal attribute mechanism to store the ACLs, then that's fine, but we
> *CANNOT* force them to do so (especially on distributed filesystems
> like NFSv4 or AFS, in which the client simply does not have ANY access
> to the underlying ACL mechanics).
I still think it makes sence to implement the ACL and extended
attributes as two different APIs and have the ACL implementation use the
extended attributes like Andreas suggested.
I don't see the need for the extended attribute implementation to deal
with things like ordering of EAs (if the order is important the data
should be in one EA instead of multiple) and EA types.
We should, however, allow a filesystem to override the default ACL
implementation to do something different.
--
Ragnar Kj�rstad
Big Storage
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
