-------- Original Message -------- Subject: XATTRs in NFS Date: Mon, 28 Oct 2013 15:41:37 -0700 From: Marc Eshel <eshel@xxxxxxxxxx> To: Marc Eshel <eshel@xxxxxxxxxx> CC: Mailing List Linux NFS <linux-nfs@xxxxxxxxxxxxxxx>, nfsv4@xxxxxxxx, nfsv4-bounces@xxxxxxxx This is a clean start to discuss extended attributes over NFS in the mailing list first. 1. What are the requirements and why? which applications are using them and how.
Reiterating, one of the applications (glusterfs - a distributed filesystem) has been using filesystems with extended attribute support by annotating files and dirs with crucial info for its operation (uses xattrs as a dumb key/value store). Usage of xattrs is crucial for the operation as glusterfs avoids using any sort of "external" meta-data database or metadata server for its operation (as a philosophy/design principle focused on robustness). Lack of xattrs on NFS prevents using NFS volumes as gluster bricks.
To that end, if NFS can map user.XXX values to user.XXX named attributes and vice versa in the NFS client and NFS server respectively, that would make NFS volumes be usable as gluster bricks.
2. Why are current named attributes in NFS not the right answer.
I think they might be, if we can map user.XXXX xattrs to named attributes and avoid any sort of interpretation of they key/values by NFS. Though from my point of view, all I care is for getxattr/setxattr of user.XXX keys to "just work" (whether they are mapped to named attributes or implemented as a separate feature).
Avati
3. What does the new protocol enhancements should look like? Thanks, Marc.
-- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
