[Gluster-devel] Adding ACLs and Extended Attributes to GlusterFS
Michael Cassaniti
m.cassaniti at gmail.com
Thu Jun 18 07:28:44 UTC 2009
Hi,
I was thinking of working on adding ACL and Extended Attribute (EA) support
to GlusterFS. I am not a programmer, although I have some experience from
Uni. I haven't yet looked at the code either, but I thought I would write
down where I think changes may need to be made, and move from there.
1. Going from the server side, a function call would need to be made to
the OS for the underlying file system. Any error codes this call made would
need to be propagated back to the client end, much as would be done for a
file permissions change.
2. At the client end, the ability to make ACL and EA function calls would
need to be exposed to the FUSE API so they could be called.
Now we effectively have both ends of the path covered (start and end
points).
3. In the middle is the transport between all translators. I believe that
whatever action and effective path is taken on a permissions change/lookup
should be the same one for ACL and EA support.
For instance, the write-behind translator *may* need to cache the write
operations of ACL and EA operations. It really should model what occurs for
permissions. Similarly, if permissions are cached in io-cache, it may be
feasible to cache ACL and EA data. EA may be skipped, but ACL I would assume
is as important as POSIX permissions.
Naturally other translators do not 'touch' file permissions, so they
would not need to take action on ACL and EA operations.
Any schedulers would need to decide the appropriate path ACL and EA
operations should take.
If the replicate translator is used with metadata locks, then ACL and EA
metadata locking should also be done.
Can someone let me know if I am on the correct path, or if I should start in
a totally different direction. I am trying to assess what code would require
modification. Also, is it suggestible to write a new translator to expose
ACL and EA support of the underlying file system, say just above the
storage/posix translator, or should it be part of the storage/posix
translator?
Any constructive help is appreciated.
Thank you,
Michael Cassaniti
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20090618/6e5d6b34/attachment-0003.html>
More information about the Gluster-devel
mailing list