On Thu, Jan 26, 2023 at 12:18:45AM +0100, Jan Stary 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.
The filesystem has no way to tell that. e.g. there could be rm
followed by inode re-use. So dump *has* to be conservative and
consider both mtime and ctime changes.
-Otto
>
> 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?
>
> Jan
>
