Adding ACLs and Extended Attributes to GlusterFS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux