Does duplicity modify atime?

Asked by Tim on 2018-04-30

My data resides on a SSD and — thanks to Write Amplification — any modification of an atime will result in not only the inode being modified, but the whole block that it resides on being erased and rewritten. That is, obviously, undesirable.

When Duplicity backs up files, does it modify the atime attribute of the source files in the process?

Question information

Language:
English Edit question
Status:
Solved
For:
Duplicity Edit question
Assignee:
No assignee Edit question
Solved by:
Kenneth Loafman
Solved:
2018-04-30
Last query:
2018-04-30
Last reply:
2018-04-30
edso (ed.so) said : #1

On 30.04.2018 02:52, Tim wrote:
> New question #668404 on Duplicity:
> https://answers.launchpad.net/duplicity/+question/668404
>
> My data resides on a SSD and — thanks to Write Amplification — any modification of an atime will result in not only the inode being modified, but the whole block that it resides on being erased and rewritten. That is, obviously, undesirable.
>
> When Duplicity backs up files, does it modify the atime attribute of the source files in the process?
>

afaik. atime is a file system feature, which needs to be disabled in the file system as a mount option if it is not wanted (noatime, nodiratime). not sure what the implications for a system disk are though if you do so.

..ede/duply.net

Tim (t69) said : #2

Yes, atime is a filesystem feature. But it is possible to programatically read and store the original atime, then read the file, then restore the original atime — using utimes() — such that atime effectively does not change. I am wondering if Duplicity 'preserves' the original atime in such a manner.

edso (ed.so) said : #3

On 30.04.2018 11:22, Tim wrote:
> Question #668404 on Duplicity changed:
> https://answers.launchpad.net/duplicity/+question/668404
>
> Status: Answered => Open
>
> Tim is still having a problem:
> Yes, atime is a filesystem feature. But it is possible to
> programatically read and store the original atime, then read the file,
> then restore the original atime — using utimes() — such that atime
> effectively does not change. I am wondering if Duplicity 'preserves'
> the original atime in such a manner.
>

given the age of the original source i'd guess not. if you really want to know you can easily check the sources yourself, or easier create a test dataset. back it up and check atimes before and after.

@Ken: do you know it off the top of your head?

..ede/duply.net

edso (ed.so) said : #4

On 30.04.2018 11:22, Tim wrote:
> Tim is still having a problem:
> Yes, atime is a filesystem feature. But it is possible to
> programatically read and store the original atime, then read the file,
> then restore the original atime — using utimes() — such that atime
> effectively does not change. I am wondering if Duplicity 'preserves'
> the original atime in such a manner.

- just two more thoughts -

1.
it looks like the approach above does write atime 2times to the fs, once during read, second during restoration of the old atime, which sounds counterproductive to your initial desire to cirumvent writing to your SSD.

2.
a quick web search provided
 https://stackoverflow.com/questions/16464228/python-get-last-reading-time-of-a-file
where it is hinted that _relatime_ only does atime update if the stored atime is older than 24hs.

..ede/duply.net

duplicity does not modify atime, but it will modify mtime during a
restore. You control FS atime mods at mount time. Turn it off for SSDs if
you wish.

...Ken

On Mon, Apr 30, 2018 at 4:43 AM, edso <email address hidden>
wrote:

> Question #668404 on Duplicity changed:
> https://answers.launchpad.net/duplicity/+question/668404
>
> edso proposed the following answer:
> On 30.04.2018 11:22, Tim wrote:
> > Tim is still having a problem:
> > Yes, atime is a filesystem feature. But it is possible to
> > programatically read and store the original atime, then read the file,
> > then restore the original atime — using utimes() — such that atime
> > effectively does not change. I am wondering if Duplicity 'preserves'
> > the original atime in such a manner.
>
> - just two more thoughts -
>
> 1.
> it looks like the approach above does write atime 2times to the fs, once
> during read, second during restoration of the old atime, which sounds
> counterproductive to your initial desire to cirumvent writing to your SSD.
>
> 2.
> a quick web search provided
> https://stackoverflow.com/questions/16464228/python-get-
> last-reading-time-of-a-file
> where it is hinted that _relatime_ only does atime update if the stored
> atime is older than 24hs.
>
> ..ede/duply.net
>
> --
> You received this question notification because your team duplicity-team
> is an answer contact for Duplicity.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~duplicity-team
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~duplicity-team
> More help : https://help.launchpad.net/ListHelp
>

Tim (t69) said : #6

Thanks Kenneth Loafman, that solved my question.