1 Aug
2019
1 Aug
'19
9:51 p.m.
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
2 Aug
2 Aug
2:03 a.m.
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(a)ceph.io
> To unsubscribe send an email to dev-leave(a)ceph.io
>
>
2:53 p.m.
On 2019-08-01T19:03:11, Sage Weil <sage(a)newdream.net> wrote:
Well, [gs]etfattr exist, so not too bad, but I agree:
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?
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)
3:54 p.m.
On Fri, Aug 02, 2019 at 09:53:05AM +0200, Lars Marowsky-Bree wrote:
On 2019-08-01T19:03:11, Sage Weil
<sage(a)newdream.net> wrote:
Well, [gs]etfattr exist, so not too bad, but I agree:
Agreed. I suppose cephfs-shell could offer an interface without a
mount (if it
doesn't already)
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?
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.
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(a)ceph.io
To unsubscribe send an email to dev-leave(a)ceph.io
--
Jan Fajerski
Engineer Enterprise Storage
SUSE Linux GmbH, GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
6 Aug
6 Aug
11:25 p.m.
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
2 Aug
2 Aug
2:07 a.m.
On Thu, Aug 1, 2019 at 7:54 AM Jan Fajerski <jfajerski(a)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
1732
days inactive
1737
days old
5 comments
5 participants
participants (5)
-
David Disseldorp -
Jan Fajerski -
Lars Marowsky-Bree -
Patrick Donnelly -
Sage Weil