On Thu, Jan 19, 2017 at 12:36:24PM -0500, Jean-Francois Malouin wrote: > * Jean-Louis Martineau <jmartin...@carbonite.com> [20170119 10:29]: > > On 19/01/17 09:49 AM, Jean-Francois Malouin wrote: > > > Hi,, > ... > > > > > > > > > Question: are they any drawbacks, performance, etc, when setting > > > property "ATIME-PRESERVE" "NO" ? > > The atime of each file/dir tar read will be modified, that's means many > > write to the disk. > > Hmmm, that's not good.
YMMV of course, but I doubt it would be a bad hit. For more than half amanda's existance gnutar did not have the atime-preserve option. Inodes (where [acm]times are kept) are not read into memory one at a time, but as a blocks of perhaps 16 or 32 inodes. They are not written back to disk with every small change. Many filesystems try to keep groups of files near to their metadata so tar may be working on several files from the same group of inodes further reducing the actual disk writes. > Would it be possible (and advisable) to force the client to use the BSD > tar in /usr/bin/tar rather than /usr/local/bin/gtar: > I don't know what file system types BSD uses, but many of the FS on Linux have mount options that affect atime updates. Current linux practice is to default to the "relatime" option which only updates atime if the file's data is modified or if the old atime is > 24 hrs earlier. If the BSD FSs have similar options and you are worried about performance, the set the mount options and don't use the tar option. I kinda like knowing the most recent time a file was read (other than for backup), so when I remember, I turn off the atime mount options. Jon -- Jon H. LaBadie j...@jgcomp.com 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (703) 935-6720 (C)
