[LU-13951] How to get the timestamp of a file data_version's last change

• Status: Open
• Project: Lustre
• Affects Version/s: Lustre 2.12.5
• Type: Improvement
• Priority: Minor
• Reporter: Stephane Thiell
• Assignee: Peter Jones
• Resolution: Unresolved

Environment

CentOS 7.6

Description

Hello! On Fir storage, we're tracking time when a file's content was last modified. Not the mtime, but the effective time when the file's content had changed. Indeed, we prefer not to rely on the file's mtime which is easily modified by touch.

To mitigate this, we currently record files' data_version in Robinhood DB along with a timestamp (max of ctime and mtime). Our purge policy is based on data_version, and if it hasn't changed for 3 months, that means the content has not changed and we purge the file. While this solution works for us, it's not lightweight and it would be easier for us if Lustre could make the last time data_version was updated in Lustre accessible via the liblustreapi.

I don't know how difficult it would be to implement this feature, but this is something that could be useful. Thanks!

Comments

[Andreas Dilger]

Hi Stephane, I was thinking about how this might be achieved without adding too much overhead. My understanding is that the concern is primarily about "touch" moving the timestamp forward without actually modifying the file data, and the overhead relates to storing the data_version value in RBH? Otherwise, if the data_version is stored in RBH, and checked periodically (e.g. at most once a day) when files appear in the Changelog, it isn't clear that storing a separate timestamp in Lustre just for this purpose.

One idea that I had was that if "touch" is moving the mtime forward, then this could be stored only on the MDT (which is enough that "stat()" will return the correct value), and the OST mtimes do not need to be updated in the setattr case. For mtimes being moved backward the OST mtimes also need to be updated, but I don't think that is a concern. This would allow the OST object mtimes to be used as an actual "last data modified" time, if there was an interface to return those timestamps to userspace on the client.

For the userspace interface, there is already IOC_MDC_GETFILEINFO that retrieves the layout and the stat (or statx) data, but the kernel side specifically avoids getting attributes from the OSTs if it can, to minimize overhead. Having a companion interface that only gets the OST attributes would be possible, possibly as a companion/extension of LL_IOC_DATA_VERSION would be possible. This ioctl is declared properly:

enum ioc_data_version_flags {
        LL_DV_RD_FLUSH  = (1 << 0), /* Flush dirty pages from clients */
        LL_DV_WR_FLUSH  = (1 << 1), /* Flush all caching pages from clients */
        LL_DV_TIMESTAMP = (1 << 2), /* Last data_version update time */
};

struct ioc_data_version {
        __u64   idv_version;
        __u32   idv_layout_version; /* FLR: layout version for OST objects */
        __u32   idv_flags;          /* enum ioc_data_version_flags */
};
#define LL_IOC_DATA_VERSION             _IOR('f', 218, struct ioc_data_version)

struct ioc_data_version_v2 {
        __u64   idv_version;
        __u32   idv_layout_version; /* FLR: layout version for OST objects */
        __u32   idv_flags;          /* enum ioc_data_version_flags */
        __u64   idv_timestamp;      /* last data_version modification time */
};
#define LL_IOC_DATA_VERSION_V2          _IOR('f', 218, struct ioc_data_version_v2)

in that if the size of struct ioc_data_version is increased to include a __u64 idv_timestamp then it would introduce a new ioctl number ("version") for LL_IOC_DATA_VERSION_V2 that could be used for compatibility/interop detection and fallback. There could also be a new LL_DV_TIMESTAMP flag to indicate whether the timestamp is requested or not.

Note that this mechanism wouldn't work for DoM files, because there is not a separate mtime stored for the MDT inode, unlike the OST inode mtime which could be used to only reflect the "data" timestamp.

That said, I don't think there is anyone on our side that would be working on this in the near future, as we already have our hands full with other projects and the cutoff for 2.14 features has already behind us.