On Tue, Feb 25, 2014 at 12:58:21AM +0100, Charles Stroom wrote: ... > > no tape, goes faster. The ps showed: > > root 7728 7723 2 00:13 ? 00:00:04 /bin/tar --create > --file - --directory /home/charles --one-file-system > --listed-incremental /var/amanda/gnutar-lists/fiume.localnethome-charles_1.new > --sparse --ignore-failed-read --totals > --exclude-from /tmp/amanda/sendbackup.home-charles.20140225001323.exclude . > amanda 7729 7727 0 00:13 ? 00:00:00 sh -c /bin/tar -tf - > 2>/dev/null | sed -e 's/^\.//' amanda 7730 7729 0 00:13 ? > 2>00:00:00 /bin/tar -tf - root 7911 4644 0 00:15 pts/1 > 2>00:00:00 grep --color=auto /bin/tar > > However, although the report said that home-charles was a level 1 dump, > it was actually a complete dump, so again wrong > > Jon was mentioning the "--atime-preserve" option, but that does seem to > be used.
I assume you meant "does not seem to be used". > Reading about tar at the gnu org web site I found that: > "Incremental dumps depend crucially on time stamps, so the results are > unreliable if you modify a file's time stamps during dumping (e.g., > with the ‘--atime-preserve=replace’ option), or if you set the clock > backwards." And than there is a discussion about "a special > O_NOATIME option from the underlying operating system" (I think that is > what Jon was referring to) and how unreliable this all is. Yes, I suspect that O_NOATIME is the open(2) or fcntl(2) option. It has been available in linux since kernel 2.6.8. But it doesn't have to be compiled into the kernel. I don't have the document in front of me, but my take on "unreliable" was available or not available. In addition to not available, remote filesystems (eg. nfs or samba mounts) would not honor the option. Jon > Jon LaBadie <[email protected]> wrote: > > > Had another thought. All the files you back up are read; > > by tar! Can you check your logfiles for the options tar > > uses, both when doing the actual dumps and during the > > estimate phase. > > > > Gnutar has a "--atime-preserve" option. Tar notes the a/mtime > > stamps and after backing up the file it resets the atime. You > > can do something similar with the touch command. > > > > "atime-preserve" can take one of two "modes", "replace" or > > "system". Some kernels have a system call that allows setting > > atime/mtime without changing ctime (only allowed for root). > > If the mode is "system" tar tries to use that feature. But > > if the kernel does not have that feature (I don't know its > > name) then the "replace" mode is used. But this mode definitely > > resets ctime to the current time. And I think that new ctime > > would cause the file to be backed up again the next amdump. > > > > According to my tar manpage, the "--listed-incremental" option > > is incompatible with "--atime-preserve=replace". > > > > Jon > > -- > > Jon H. LaBadie [email protected] > > 11226 South Shore Rd. (703) 787-0688 (H) > > Reston, VA 20190 (609) 477-8330 (C) > > > -- > Charles Stroom > email: charles at no-spam.stremen.xs4all.nl (remove the "no-spam.") >>> End of included message <<< -- Jon H. LaBadie [email protected] 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (609) 477-8330 (C)
