On Wed, Jan 25, 2023 at 4:35 PM Jan Stary <[email protected]> wrote: > On Jan 26 00:18:45, [email protected] wrote: > > I have a large /media disk that I backup nightly using dump(8): > > full level 0 on the Sun/Mon night, incrementals through the week. > > The level 0 dump is huge, the incrementals are usualy trivial > > unless I add something to /media. > > > > Yesterday I chmod'd a lot of the files, without making any other change. > > That resulted in a huge level 2 dump; I suppose a chmod change counts > > as a changed file, so they all got dumped anew, even though the content > > of the file(s) has not changed. > > > > Is that intentional? It seems there is a lot of space to be saved > > if it's "only" the metadata that have changed. Is that decided by > > simply looking at the stat(2)? In particular, newer ctime is > > just as good a reason to dump the _content_ as newer mtime? > > Seems so: > > /* Determine if given inode should be dumped */ > [...] > if (CHECKNODUMP(dp) && > (DIP(dp, di_mtime) >= spcl.c_ddate || > DIP(dp, di_ctime) >= spcl.c_ddate)) { >
Right: if the ctime is newer than the previous backup then you don't know what else has changed: the contents could have been modified and then the file's mtime backdated to before the previous backup. At that point the ctime is the only indicator that the file no longer matches its backup. (Of course, the second problem that follows from that limitation is that the 'dump' format doesn't have a way to record inode-only info (like mode, times, and flags) without also recording the file contents. So, even if the filesystem provided enough info for dump to know that only the file's mode had been changed, there's nothing it can do about it other than back up the entire file.) Philip Guenther
