immutable file support in cephfs
Hi, I'd questions around feature tracker, https://tracker.ceph.com/issues/10679 that requests for chattr +i support in cephfs, and wanted to check whether the earlier discussed approach is still good [1]. A while ago, John Spray suggested that the S_IMMUTABLE flag be stored in the high bits of the cephfs inode's mode attribute as the inode doesn't have the i_flags attribute. The cephfs inode's mode attribute has 32 bits, and seems like only 16 bits are used for access modes and file type. In comparison, ext4 inode's mode attribute and i_flags attribute are 16 bits and 32 bits respectively. Should we store the S_IMMUTABLE flag in the mode attribute, or in a new i_flags attribute? e2fsprogs' chattr uses FS_IOC_[GS]ETFLAGS ioctls to get/set the S_IMMUTABLE flag of an inode. The two ioctls need to be added to the kernel and FUSE clients as mentioned in [2]. Maybe later if required we can add the FS_IOC_FS[GS]ETXATTR ioctls [3] that can also get/set inode flags. What interfaces should libcephfs use to get/set the immutable bit flag? Sage suggested that the MDS check for the S_IMMUTABLE flag, and not issue write caps if set, and the clients also check for the flag and return suitable errno to avoid waiting for the caps. Does this enforcement sound good? Note that data of immutable files can be modified using open fds existing prior to the immutable flag being set on files in linux file systems[4]. Thanks, Ramana [1] https://www.spinics.net/lists/ceph-users/msg15221.html [2] https://www.spinics.net/lists/ceph-users/msg15224.html [3] https://lore.kernel.org/linux-fsdevel/1451886892-15548-1-git-send-email-davi... [4] https://lwn.net/Articles/786258/
On Tue, 2021-04-13 at 17:46 -0400, Ramana Venkatesh Raja wrote:
Hi,
I'd questions around feature tracker, https://tracker.ceph.com/issues/10679 that requests for chattr +i support in cephfs, and wanted to check whether the earlier discussed approach is still good [1].
A while ago, John Spray suggested that the S_IMMUTABLE flag be stored in the high bits of the cephfs inode's mode attribute as the inode doesn't have the i_flags attribute. The cephfs inode's mode attribute has 32 bits, and seems like only 16 bits are used for access modes and file type. In comparison, ext4 inode's mode attribute and i_flags attribute are 16 bits and 32 bits respectively. Should we store the S_IMMUTABLE flag in the mode attribute, or in a new i_flags attribute?
I wouldn't overload it onto the mode field. That's "clever" but not particularly helpful. I think the main place you're going to need to store this is in struct inode_t, right? If so, then there are some existing holes in that structure that you could use to add a new flags field (or maybe just an immutable bool) without growing it. In practice, _storing_ this info is not going to be too difficult, I think. The harder part here is revving the protocol to carry this flag in the appropriate network messages, and fixing up the client and MDS to handle it.
e2fsprogs' chattr uses FS_IOC_[GS]ETFLAGS ioctls to get/set the S_IMMUTABLE flag of an inode. The two ioctls need to be added to the kernel and FUSE clients as mentioned in [2]. Maybe later if required we can add the FS_IOC_FS[GS]ETXATTR ioctls [3] that can also get/set inode flags. What interfaces should libcephfs use to get/set the immutable bit flag?
You'll probably want to add a new call to libcephfs for this (ceph_set_immutable() or something).
Sage suggested that the MDS check for the S_IMMUTABLE flag, and not issue write caps if set, and the clients also check for the flag and return suitable errno to avoid waiting for the caps. Does this enforcement sound good? Note that data of immutable files can be modified using open fds existing prior to the immutable flag being set on files in linux file systems[4].
Yeah, that sounds fine.
[1] https://www.spinics.net/lists/ceph-users/msg15221.html [2] https://www.spinics.net/lists/ceph-users/msg15224.html [3] https://lore.kernel.org/linux-fsdevel/1451886892-15548-1-git-send-email-davi... [4] https://lwn.net/Articles/786258/ _______________________________________________ Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io
-- Jeff Layton <jlayton@redhat.com>
participants (2)
-
Jeff Layton
-
Ramana Venkatesh Raja