From ah@alvman.Haakh.de  Fri Sep 28 01:14:11 2001
Return-Path: <ah@alvman.Haakh.de>
Received: from mailout04.sul.t-online.de (mailout04.sul.t-online.com [194.25.134.18])
	by hub.freebsd.org (Postfix) with ESMTP id CD1DC37B409
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 28 Sep 2001 01:14:07 -0700 (PDT)
Received: from fwd02.sul.t-online.de 
	by mailout04.sul.t-online.de with smtp 
	id 15msmY-0004EV-04; Fri, 28 Sep 2001 10:14:02 +0200
Received: from alvman.Haakh.de (320092418718-0001@[217.80.77.170]) by fmrl02.sul.t-online.com
	with esmtp id 15msmT-2Hx5KSC; Fri, 28 Sep 2001 10:13:57 +0200
Received: (from ah@localhost)
	by alvman.Haakh.de (8.11.6/8.11.5) id f8S8DuF62730;
	Fri, 28 Sep 2001 10:13:56 +0200 (CEST)
	(envelope-from ah)
Message-Id: <200109280813.f8S8DuF62730@alvman.Haakh.de>
Date: Fri, 28 Sep 2001 10:13:56 +0200 (CEST)
From: Andreas Haakh <ah@Haakh.de>
Reply-To: Andreas Haakh <ah@Haakh.de>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: dump allways saves files with modified c-time
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         30887
>Category:       bin
>Synopsis:       dump allways saves files with modified c-time
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Fri Sep 28 01:20:00 PDT 2001
>Closed-Date:    Thu Jun 06 09:43:25 PDT 2002
>Last-Modified:  Thu Jun 06 09:43:25 PDT 2002
>Originator:     Andreas Haakh
>Release:        FreeBSD 4.4-STABLE i386
>Organization:
Ingenieurbro fr Baustatik
>Environment:
System: FreeBSD alvman.Haakh.de 4.4-STABLE FreeBSD 4.4-STABLE #0: Thu Sep 20 15:47:07 CEST 2001 root@alvman.Haakh.de:/usr/src/sys/compile/ALVMAN i386


>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
	add another flag to dump and ignore c-time, based on this flag.

	A solution/workaround is to ignore c-time in the CHANGEDSINCE-macro 
	in /usr/src/sbin/dump/traverse.c

/* Auxiliary macro to pick up files changed since previous dump. */
 #define CHANGEDSINCE(dp, t) \
-       ((dp)->di_mtime >= (t) || (dp)->di_ctime >= (t))
+       ((dp)->di_mtime >= (t))

	
>Release-Note:
>Audit-Trail:

From: "Crist J. Clark" <cristjc@earthlink.net>
To: Andreas Haakh <ah@Haakh.de>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/30887: dump allways saves files with modified c-time
Date: Fri, 28 Sep 2001 03:04:05 -0700

 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

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
 --
 Ingenieurbro fr Baustatik *  Dipl.-Ing. Andreas Haakh
 Mollerstrae 7  *  64289 Darmstadt  *  Andreas@Haakh.de
 Tel. 06151-788361 Fax. 06151-788362 Mobil 0173-361.6884
 
State-Changed-From-To: open->closed 
State-Changed-By: obrien 
State-Changed-When: Thu Jun 6 09:42:44 PDT 2002 
State-Changed-Why:  
chflags(1) now has a nodump flag which dump(8) respects. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=30887 
>Unformatted:
