Hi list, while discussing the snap-schedule module, a feature request for protecting snapshots against deletion came up. This is partly tied to the scheduled pruning, when a user wants to protect an individual snapshot from being pruned. It could however also be used to protect individual snapshots from being accidentally deleted. One proposed interface (thx Lars) would be to implement a new extended attribute on snapshot directories. I like this as an interface as its quiet flexible and could be build upon (by say a mgr module command). Does snapshot deletion involve the MDS? Otherwise older clients not aware might still delete them (like quotas depend on client cooperation) Is a virtual xattr on a virtual directory a bad idea? Other concerns or better ideas? Best, Jan
On Thu, 1 Aug 2019, Jan Fajerski wrote:
Hi list, while discussing the snap-schedule module, a feature request for protecting snapshots against deletion came up. This is partly tied to the scheduled pruning, when a user wants to protect an individual snapshot from being pruned. It could however also be used to protect individual snapshots from being accidentally deleted.
This sounds useful!
One proposed interface (thx Lars) would be to implement a new extended attribute on snapshot directories. I like this as an interface as its quiet flexible and could be build upon (by say a mgr module command).
Does snapshot deletion involve the MDS? Otherwise older clients not aware might still delete them (like quotas depend on client cooperation)
The snapshot removal is a distinct request to the MDS, normally (only?) triggered by an rmdir on the virtual snapshot directory. There shouldn't be any problem with teh MDS doing any checks (and returning EPERM or whatever as needed).
Is a virtual xattr on a virtual directory a bad idea?
Seems fine to me. It is a bit awkward from the command line, though. What about 'chattr +e' (or 'chattr -e'), which normally sets the immutable flag for local file systems? sage
Other concerns or better ideas?
Best, Jan _______________________________________________ Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io
On 2019-08-01T19:03:11, Sage Weil <sage@newdream.net> wrote:
Is a virtual xattr on a virtual directory a bad idea? Seems fine to me. It is a bit awkward from the command line, though.
Well, [gs]etfattr exist, so not too bad, but I agree:
What about 'chattr +e' (or 'chattr -e'), which normally sets the immutable flag for local file systems?
Yes, I think that's better. (Though I think you mean "i", not "e"?) One of the reasons for why we considered xattrs though was that it'd allow us to store some more metadata associated with the snap. Consider - when creating a snap of "dir", is the ctime/mtime of the dir/.snap/name now the values of "dir/." at the time of the snapshot, or the snapshot creation time? I think the the former would make more sense, but where then to store the snap creation time? Let's stuff it into an xattr. Similarly, we talked to someone very familiar with NetApp, and they mentioned that it can be hard to figure out when/who/why a snap was created. That's information we could store in the mgr module, but that makes it somewhat more awkward. Having this in xattr metadata would be useful and consistent (and accessible through standard CLI tools and calls). (e.g., even if the free-form-ish description wasn't populated automatically, the MDS could auto-fill the timestamp and uid/host that triggered the snap.) Thus we ended up thinking that the immutable flag might belong in there as well. But since there is a dedicated file attribute for that, I agree that this flag is a better fit. Regards, Lars -- SUSE Linux GmbH, GF: Felix Imendörffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nürnberg) "Architects should open possibilities and not determine everything." (Ueli Zbinden)
On Fri, Aug 02, 2019 at 09:53:05AM +0200, Lars Marowsky-Bree wrote:
On 2019-08-01T19:03:11, Sage Weil <sage@newdream.net> wrote:
Is a virtual xattr on a virtual directory a bad idea? Seems fine to me. It is a bit awkward from the command line, though.
Well, [gs]etfattr exist, so not too bad, but I agree:
What about 'chattr +e' (or 'chattr -e'), which normally sets the immutable flag for local file systems?
Yes, I think that's better. (Though I think you mean "i", not "e"?) Agreed. I suppose cephfs-shell could offer an interface without a mount (if it doesn't already)
One of the reasons for why we considered xattrs though was that it'd allow us to store some more metadata associated with the snap.
Consider - when creating a snap of "dir", is the ctime/mtime of the dir/.snap/name now the values of "dir/." at the time of the snapshot, or the snapshot creation time?
I think the the former would make more sense, but where then to store the snap creation time? Let's stuff it into an xattr. We have this already. When mkdir .snap/foo we have the snapshots ctime from .snap/foo while preserving the contents ctimes, mtime and atime.
Similarly, we talked to someone very familiar with NetApp, and they mentioned that it can be hard to figure out when/who/why a snap was created. That's information we could store in the mgr module, but that makes it somewhat more awkward. Having this in xattr metadata would be useful and consistent (and accessible through standard CLI tools and calls). So we have the When covered. Do we really need Who and Why in an xattr?
(e.g., even if the free-form-ish description wasn't populated automatically, the MDS could auto-fill the timestamp and uid/host that triggered the snap.)
Thus we ended up thinking that the immutable flag might belong in there as well. But since there is a dedicated file attribute for that, I agree that this flag is a better fit.
Regards, Lars
-- SUSE Linux GmbH, GF: Felix Imendörffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nürnberg) "Architects should open possibilities and not determine everything." (Ueli Zbinden) _______________________________________________ Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io
-- Jan Fajerski Engineer Enterprise Storage SUSE Linux GmbH, GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg)
Hi Lars, On Fri, 2 Aug 2019 09:53:05 +0200, Lars Marowsky-Bree wrote:
Consider - when creating a snap of "dir", is the ctime/mtime of the dir/.snap/name now the values of "dir/." at the time of the snapshot, or the snapshot creation time?
"dir/." at the time of the snapshot.
I think the the former would make more sense, but where then to store the snap creation time? Let's stuff it into an xattr.
It's available via the new "ceph.snap.btime" vxattr. This was added for Samba Previous Versions support. Cheers, David
On Thu, Aug 1, 2019 at 7:54 AM Jan Fajerski <jfajerski@suse.com> wrote:
Hi list, while discussing the snap-schedule module, a feature request for protecting snapshots against deletion came up.
Where/when did this discussion happen? +Venky/+Daniel have been planning work on this and should be in the loop.
This is partly tied to the scheduled pruning, when a user wants to protect an individual snapshot from being pruned. It could however also be used to protect individual snapshots from being accidentally deleted.
Another possibility would be to have a snapshot copy operation. Then the snapshot with a generated schedule based name could be saved by the user. I don't know yet how technically difficult that would be.
Is a virtual xattr on a virtual directory a bad idea?
No, it's fine. -- Patrick Donnelly, Ph.D. He / Him / His Senior Software Engineer Red Hat Sunnyvale, CA GPG: 19F28A586F808C2402351B93C3301A3E258DD79D
participants (5)
-
David Disseldorp
-
Jan Fajerski
-
Lars Marowsky-Bree
-
Patrick Donnelly
-
Sage Weil