[lustre-devel] [PATCH RFC] lustre: llite: add LL_IOC_FUTIMES_3
neilb at suse.com
Mon Nov 26 14:28:35 PST 2018
On Mon, Nov 26 2018, Andreas Dilger wrote:
> On Nov 26, 2018, at 14:15, NeilBrown <neilb at suse.com> wrote:
>> On Mon, Nov 26 2018, James Simmons wrote:
>>> Add a new regular file ioctl LL_IOC_FUTIMES_3 similar to futimes() but
>>> which allows setting of all three inode timestamps. Use this ioctl
>>> during HSM restore to ensure that the volatile file has the same
>>> timestamps as the file to be restored. Strengthen sanity-hsm test_24a
>>> to check that archive, release, and restore do not change a file's
>>> ctime. Add sanity-hsm test_24e to check that tar will succeed when it
>>> encounters a HSM released file.
>> What is this used for? What is the minimum functionality that would be
> Correct, this is for restoring files from HSM archive or migrating between
> different tiers of storage within the filesystem. This is transparent to the user, and we don't want the migration/restore to cause the file to be backed up again.
>> I'm guessing that it is used to migrate files between different levels
>> in the HSM storage hierarchy. Why is it important that the ctime not
>> change? How is the ctime used in a way that would be confused?
>> Would it be sufficient, for example, to be able to set the ctime to the
>> same as the mtime?
> There are lots of different kinds of backup tools out there, I can't
> comment on whether ctime == mtime is sufficient to avoid triggering
> another backup cycle. Keeping the same timestamps over this process
> is safest. It seems that XFS has a similar requirement, and it is
> using "FMODE_NOCMTIME", but that only avoids updating the timestamps,
> it doesn't allow setting them.
Interesting.. FMODE_NOCMTIME was added 10 years ago (next month) with
+ * Currently a special hack for the XFS open_by_handle ioctl, but we'll
+ * hopefully graduate it to a proper O_CMTIME flag supported by open(2) soon.
"soon" is an imprecise term of course...
But as you say, there is no way to set the ctime, even at file creation.
I wonder how this is used.
Maybe it would make sense to add a flag to utimensat() to expect a third
time-stamp and use that for ctime. That would be a fairly simple and
safe API change.
It would be nice to creae an O_NOCMTIME and plumb it through properly
Possibly utimensat(AT_3TIMES) would required an fd that was opened with
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 832 bytes
Desc: not available
More information about the lustre-devel