Hello Torsten, Here is a draft of a new file Documentation/filesystems/aufs/design/06xattr.txt. I want you (or anyone) to take a look and send comments back, particulary about - new branch attrib. - the behaviour of getxattr(2) and listxattr(2).
Thanx in advance J. R. Okajima XATTR/EA suppor in the internal (copy,move)-(up,down) ---------------------------------------------------------------------- Generally the extended attributes of inode are categorazied as these. - "security" for LSM and capability. - "system" for posix ACL, 'acl' mount option is required. - "trusted" for userspace, CAP_SYS_ADMIN is required. - "user" for userspace, 'user_xattr' mount option is required. Moreover there are some other categories. These rather unpopular categories are handled as ... In the copy-up operation, aufs should copy *all* the attibutes from the source branch fs to the destination branch fs. But the support for XATTR on the dst branch may differ from the src branch. In this case, the copy-up operation will get an error and the original user operation which triggered the copy-up fails. It can happen that evan all copy-up will fail. When both of src and dst branches support XATTR and the copying XATTR get an error, then the copy-up should fail obviously. That is a good reason and aufs should return an error to userspace. But when only the dst branch support XATTR, aufs should not return an error. Moreover aufs should not try copying XATTR to the XATTR-unsupported branch. In order to support XATTR and to implement the correct behaviour, there introduces some new attributes for aufs branches, "ea_sec", "ea_tr", and "ea_usr". They correspond to the XATTR namespaces (see above). Note that "ea_sys" for "system" doesn't exist. Since VFS has a generic flag MS_POSIXACL, aufs can know whether the branch fs supports "system" xattr or not. After the branch has these attributes, the XATTR copy-up operation between branches are done only if the attribute matches. For example, - "ea_sec" is set to the lower/source branch. - "ea_sec" is NOT set to the upper/destination branch. Then aufs won't try copy-up the "security" XATTRs, and will not return an error related to XATTR. For the inode standard attributes (owner, group, timestamps, etc.), aufs shows users them the values from the topmost existing file. This behaviour is good for the non-dir entreis since the bahaviour exactly matches to the shown information. But for the directories, aufs considers the all same named entries on the lower branches. Which means, if one of the lower entry rejects readdir call, then aufs returns an error even if the topmost entry allows it. This behaviour may make users confused since the user-visible standard attributes are the topmost entry's. The similar issue can happen around XATTR. To address this issue, aufs has a mount option called dirperm1 which checks the permission for the topmost entry only. The bahaviour of getxattr(2) and listxattr(2) follows dirperm1 option. When the option is set, these systemcalls returns XATTR from the topmost entry only. Otherwise, all XATTRs from the all same named entries on the lower branches are included. ------------------------------------------------------------------------------ Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
