Bug 30887

On Fri, Sep 28, 2001 at 10:13:56AM +0200, Andreas Haakh wrote:
> >Description:
> 	dump saves all files with changend m-time or changed c-time.
> 	Large files, where only c-time is changed, e.g. mailfolders, databases
> 	etc. will be saved day after day allthough the content of the 
> 	files did not change.
> 	
> >How-To-Repeat:
> 	
> >Fix:
> 	ignore c-time anyway because there is no need to save files where only 
> 	the status has changed or

This is not true. For example, when a file is mv(1)'ed, only the ctime
will be changed, but I would expect most people would want it backed
up. Even though the data in the file is "old," you want to have a
fairly consistent snapshot of the filesystem (yes, dump(8) can only do
that to a limited degree), and backing up the moved file is the only
way to really do this.

> 	add another flag to dump and ignore c-time, based on this flag.

That's possible, but I'd have to think about what other changes you
may be missing when you start to ignore ctime.

Generally, a dump is something where you want to err on the side of
caution. You would rather archive some things redundantly than risk
missing something else. There are many examples where the very simple
approach of dump(8) results in storing files over and over. Take the
rotated *.<n>.gz logs in /var/log. Each time these get rotated, they
are stored all over again. This ctime patch would actually stop that,
but if you then were to restore your series of tapes, you would only
ever get the last *.0.gz at the end. (Unless you tried to move stuff
around between restoring tapes.)

Actually, what I think best would in addition to the nodump filesystem
flag, we could have a "noctime" flag. That is, individual files could
be marked so they would be ignored if only their ctime changes. You
could 'chflags noctime /var/mail' and fix your problem. But that fix
takes some work.
-- 
Crist J. Clark                           cjclark@alum.mit.edu

On Fri, 28 Sep 2001, Crist J. Clark wrote:

> On Fri, Sep 28, 2001 at 10:13:56AM +0200, Andreas Haakh wrote:
> > >Description:
> > 	dump saves all files with changend m-time or changed c-time.
> > 	Large files, where only c-time is changed, e.g. mailfolders, databases
> > 	etc. will be saved day after day allthough the content of the
> > 	files did not change.
> >
> > >How-To-Repeat:
> >
> > >Fix:
> > 	ignore c-time anyway because there is no need to save files where only
> > 	the status has changed or
>
> This is not true. For example, when a file is mv(1)'ed, only the ctime
> will be changed, but I would expect most people would want it backed
> up. Even though the data in the file is "old," you want to have a
> fairly consistent snapshot of the filesystem (yes, dump(8) can only do
> that to a limited degree), and backing up the moved file is the only
> way to really do this.
>
> > 	add another flag to dump and ignore c-time, based on this flag.
>
> That's possible, but I'd have to think about what other changes you
> may be missing when you start to ignore ctime.
>
> Generally, a dump is something where you want to err on the side of
> caution. You would rather archive some things redundantly than risk
> missing something else. There are many examples where the very simple
> approach of dump(8) results in storing files over and over. Take the
> rotated *.<n>.gz logs in /var/log. Each time these get rotated, they
> are stored all over again. This ctime patch would actually stop that,
> but if you then were to restore your series of tapes, you would only
> ever get the last *.0.gz at the end. (Unless you tried to move stuff
> around between restoring tapes.)
>
> Actually, what I think best would in addition to the nodump filesystem
> flag, we could have a "noctime" flag. That is, individual files could
> be marked so they would be ignored if only their ctime changes. You
> could 'chflags noctime /var/mail' and fix your problem. But that fix
> takes some work.
> --
> Crist J. Clark                           cjclark@alum.mit.edu
>

You are right. I missed the issue with mv'ed files completely.

It would be a great idea to add another flag to these files. Another
approch would be to set the archived flag on any dumped file and reset it
whenever the file is mv'ed or hard-linked.

A different solution would be to set a flag (e.g. usecflag) to any file
which has been mv'd or hard-linked forcing dump to honor the file status -
even if told to ignore cflags - and reset it after it has been dumped.
This would lead to less io on the filesystem. This flag should also be
reset, when the file is modified, thus taking the necessity from dump to
reset ist.

Andreas
--
Ingenieurbüro für Baustatik *  Dipl.-Ing. Andreas Haakh
Mollerstraße 7  *  64289 Darmstadt  *  Andreas@Haakh.de
Tel. 06151-788361 Fax. 06151-788362 Mobil 0173-361.6884

Comment 3 David E. O'Brien 2002-06-06 17:42:44 UTC

State Changed
From-To: open->closed

chflags(1) now has a nodump flag which dump(8) respects.