Date: Fri, 28 Sep 2001 06:00:03 -0700 (PDT) From: Andreas Haakh <ah@Haakh.de> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/30887: dump allways saves files with modified c-time Message-ID: <200109281300.f8SD03Q97746@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/30887; it has been noted by GNATS. From: Andreas Haakh <ah@Haakh.de> To: <cjclark@alum.mit.edu> Cc: <FreeBSD-gnats-submit@FreeBSD.ORG> Subject: Re: bin/30887: dump allways saves files with modified c-time Date: Fri, 28 Sep 2001 14:47:07 +0200 (CEST) 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200109281300.f8SD03Q97746>