[LU-3315] O_NOATIME: don't change access time after backup

• Status: Resolved
• Project: Lustre
• Affects Version/s: Lustre 1.8.7, Lustre 2.5.0
• Type: Improvement
• Priority: Major
• Reporter: Supporto Lustre Jnet2000 (Inactive)
• Assignee: Bruno Faccini (Inactive)
• Resolution: Fixed

Environment

redhat 5.7

Description

hi,

i use bacula like software of backup,when i run job and start the backup, the job modifies the access time of the files.
In bacula there is the optin noatime that don't change the access time.

"
noatime=yesno
If enabled, and if your Operating System supports the O_NOATIME file open flag, Bacula will open all files to be backed up with this option. It makes it possible to read a file without updating the inode atime (and also without the inode ctime update which happens if you try to set the atime back to its previous value). It also prevents a race condition when two programs are reading the same file, but only one does not want to change the atime. It's most useful for backup programs and file integrity checkers (and bacula can fit on both categories).

This option is particularly useful for sites where users are sensitive to their MailBox file access time. It replaces both the keepatime option without the inconveniences of that option (see below).

If your Operating System does not support this option, it will be silently ignored by Bacula. "

But this function works with filesystem ext3 but not works in lustre filesystem.

Could you make something ?

Best regards

Augusto Casciola

Issue Links

• is duplicated by: LU-3831 ll_readdir() ignores O_NOATIME

Comments

[Peter Jones]

Hi Augusto

It's always nice to have suggestions for ways to improve Lustre and, while we cannot guarantee it, we can sometimes oblige as a lower priority task in between responding to support requests.

Bruno

Are you able to advise as to what the options are presently and how much effort it might be to do as Augusto suggests on a future 2.x release?

Thanks

Peter

[Bruno Faccini (Inactive)]

Ok, I will try to evaluate the amount of work to implement, based on current/master mechanisms and with teammates advices/feed-back.
Will be back soon, but in the mean time Augusto don't hesitate to ping/ask me for progress if I miss to update the ticket enough frequently!
Bye,
Bruno.

[Bruno Faccini (Inactive)]

Hello Augusto,
Sorry to be late for this issue.
On the other hand, t appears that the same issue as been reported in LU-3831, and is likely to have been fixed by the associated patch since a long time.
Do you agree if we close this ticket as a duplicate of LU-3831?

[John Fuchs-Chesney (Inactive)]

Fixed in LU-3831 with patches landed to appropriate branches.

No response from customer in some months.
~ jfc.