On Sun, Oct 18, 2015 at 09:59:10AM +1100, Dave Chinner wrote: > For XFS userspace we also need this feature bit for xfs_repair so > that it doesn't attempt to validate the on-disk ACL format is in a > valid posix ACL format. IOWs, we need an on-disk feature bit to > indicate the on-disk format of the ACL in XFS. > > Further, a user could mount the ext4 fs with "norichacl,acl" to > force the kernel to parse the rich acls as posix acls because > without a feature bit the fs does not know what format it's acls are > in on-disk. This will only end in tears for users. So at least for ext4, the richacl xattr using a completely different index, and so it's not possible to interpret the richacl as an acl. The only question is whether we pay attention to the richacl acl's at all. One thing that's not clear to me is what VFS is supposed to do if an inode has both an Posix ACL xattr and a Richacl xattr at the same time. We're also not trying to validate the on-disk ACL format at all using e2fsck, just as we're not trying to validate say, the SELinux xattr. They are just bags of bits as far as e2fsck is concerned. So for that reason, at least as the patches I've seen for richacl for ext4, e2fsprogs doesn't actually need a file system feature bit at all. We could in theory use the 1.42 version of e2fsck against an ext4 file system with richacl, and modulo the incompat flag, there wouldn't be any problems from e2fsck point of view. What Andreas G. has said is that the only problem is if the file system is mounted read/write, and someone creates an inode on a non-richacl knowledgeable kernel, the inode would get created w/o an richacl. This might be surprising to the user if he or she was expecting richacl semantics, but that would only happen if they had say, enabled richacl's on a distribution that had full richacl support (including the richacl userspace utilities so they could set and get richacl entries), and then booted an older kernel on that distribution. This doesn't seem like _that_ likely a scenario, but I suppose it could happen. And whether you call the file system "inconsistent" really depends on your point of view. From the perspective of fsck, which for ext4 is completely, happily ignorant of richacl support, it's not inconsistent and all of the inodes are valid. > I asked this same question on the kernel side of things. While I > think that from an "on-disk consistency" POV using RO_INCOMPAT would > be fine, from a user visible POV the behaviour won't be compatible > and so INCOMPAT makes sense from that perspective. If you believe that the only real use of richacl will be primarily for supporting Samba and NFSv4 servers, then using a read-only compat feature flag isn't that terrible, and it might be helpful in the case of someone using a rescue media that hasn't been updated yet to be able to access the system --- since it seems unlikely that the user would try to launch a Samba or NFSv4 server from a rescue CD. But I different people of good will can differ with each other, and at the end of the day I don't think it makes *that* much difference unless we drop the use of the feature flag entirely. Given that systemd has infected all of the distributions, and systemd is getting more and more tightly integrated into modern kernel features w/o offerring backwards compatibility, it seems very likely to me that you wouldn't even be able to *boot* a downrev kernel on a modern distribution that has richacl support without seeing systemd or its dependencies explode into millions of tiny pleaces, so I'm not that terribly worried one way or another. :-) - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
