On Fri, Aug 02, 2019 at 09:53:05AM +0200, Lars Marowsky-Bree wrote: >On 2019-08-01T19:03:11, Sage Weil <sage@xxxxxxxxxxxx> 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@xxxxxxx >To unsubscribe send an email to dev-leave@xxxxxxx > -- Jan Fajerski Engineer Enterprise Storage SUSE Linux GmbH, GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
