"David P. Quigley": > I think it would be useful to see the source code for AUFS2 posted to > LKML. One of the questions I have not which doesn't seem to be addressed > in these documents is how robust is your xattr support and are you > making the appropriate LSM calls to make this usable with SELinux and > Smack. Also from a labeling perspective you have a very interesting > question of which label do you select when unifying directories. If you > have a/foo and b/foo each with different labels which do you choose. > Based on the history of Union type file systems I would suspect the > answer is whichever branch is listed first. Aufs doesn't support xattr curretnly because I don't decide how to support it yet. As far as I know, the implementation of xattr and its key/name pairs are filesystem dependent. For instance, - there are two branches (rw and ro) in aufs and their filesystem type differs from each other. - an application issues getxattr() or listxattr() and makes sure "key.brabra" exists (or set). - and then it issues setxattr() for "key.brabra". - aufs will copies-up the file and tries setxattr() for the upper one. - I am afraid there may happen "key.brabra" is not supported by the upper filesystem and aufs returns an error. - from the users' point of view, this behaviour must be very strange. Finally I am considering to make some levels to support xattr. - support minimum common set of key only (if such set exists) Here "minimum common set" means a group of key which are surely supported by all filesystems. Aufs will filter-out other keys. - create a new internal status flag This flag is set when the type of all branches are same. When the flag is set, aufs will handle xattr by simply redirecting. - create a new aufs mount option the option will select two behaviours (above). Unfortunately I could not understand what label means. Is it a volume label at mounting like UUID? J. R. Okajima -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
