On Tue, 19 Mar 2019, David Disseldorp wrote: > Hi, > > On Fri, 15 Mar 2019 06:51:55 -0400, Jeff Layton wrote: > > > > Ideally, having the snap-create-time in the snapshot's stx_btime would > > > make the enum + reverse lookup more efficient, as we would be able to > > > get everything via ceph_readdirplus_r(). xattr should work too though, > > > be it a little slower. > > > > > > > I wouldn't overload stx_btime with this value as it has its own meaning, > > and applications should be able to get to that value in a snapshot too. > > > > One of the goals with statx was to make a stat struct that was > > extendable. If performance is a factor then just extend ceph_statx with > > a new stx_snap_btime field. If performance is not a big deal here, then > > an xattr would probably be simpler to implement. > > I've added a virtual ceph.snap.timestamp=$secs.$nsecs xattr to the > CInode::encode_inodestat() code path on the MDS: > https://github.com/ddiss/ceph/commit/6825ba361d32a295d96fdf387965f04198b95ad1 > > I've also added corresponding Samba functionality to fetch this during > .snaps readdir(). Please let me know whether you think this is the right > spot for this, or whether the vxattr should be processed on the client > side and translated into a different (new) MDS request which explicitly > grabs SnapInfo.stamp. I think the vxattrs should definitely be processed/handled on the client side. As far as how the metadata gets there, I'd try to include it in an existing nsap structure (SnapInfo?) so that there is no need for any additional request, which will add complexity. sage
