From owner-freebsd-bugs Fri Nov 30 14:40:18 2001 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 0FA5437B41C for ; Fri, 30 Nov 2001 14:40:01 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id fAUMe1G66883; Fri, 30 Nov 2001 14:40:01 -0800 (PST) (envelope-from gnats) Received: from gro.dd.org (gro.dd.org [209.198.103.200]) by hub.freebsd.org (Postfix) with ESMTP id 0219D37B419 for ; Fri, 30 Nov 2001 14:39:17 -0800 (PST) Received: (from root@localhost) by gro.dd.org (8.11.6/8.11.6) id fAUMdB285482; Fri, 30 Nov 2001 17:39:11 -0500 (EST) (envelope-from tale) Message-Id: <200111302239.fAUMdB285482@gro.dd.org> Date: Fri, 30 Nov 2001 17:39:11 -0500 (EST) From: David C Lawrence Reply-To: David C Lawrence To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.113 Subject: bin/32414: [PATCH] dump is sometimes not propagating nodump flag Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >Number: 32414 >Category: bin >Synopsis: [PATCH] dump is sometimes not propagating nodump flag >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Nov 30 14:40:00 PST 2001 >Closed-Date: >Last-Modified: >Originator: David C Lawrence >Release: FreeBSD 4.4-STABLE i386 >Organization: personal >Environment: System: FreeBSD gro.dd.org 4.4-STABLE FreeBSD 4.4-STABLE #7: Wed Nov 7 23:11:57 EST 2001 tale@gro.dd.org:/usr/src/sys/compile/GRO i386 >Description: Files in subdirectories of directories that have the nodump flag set are sometimes incorrectly being dumped. My daily dump files for /var were shockingly large given that I had /var/log with the nodump flag on it. The table of contents from restore did not show any files that should be taking up all the space. The actual contents of the dump file, though, clearly had my large /var/log/httpd/access_log file in them. Somewhat ironically, this problem does not arise if the subdirectory is marked for dumping (because it meets the changed-since-time criteria). The problem arises because the subdirectory only gets its entry cleared from usedinomap if it is also present in dumpinomap, and it is the absence of a directory in usedinomap that internally indicates that the directory is under the effects of UF_NODUMP (either directly or inherited). >How-To-Repeat: You should be able to do this as an unprivileged user; it depends on /var being a seperate filesystem, of course. Note that it updates /etc/dumpdates with a level 8 dump, which might impact your normal dump schedule. I picked the high dump level to minimize the potential impact. #! /bin/sh D=/var/tmp/dump-test BAD='THIS SHOULD NOT BE DUMPED' mkdir -p $D/subdir chflags nodump $D echo $BAD > $D/subdir/nodump dump -8 -u -a -f /dev/null /var touch $D/subdir/nodump dump -9 -a -f /tmp/dump /var egrep "$BAD" /tmp/dump >Fix: The following patch moves the clearing of the inode in usedinomap to the block where the inode is tested to be a directory. The statement is not needed in the block it was in because usedinomap is only relevant to directory entries. --- /usr/src/sbin/dump/traverse.c.dist Sat Jul 14 09:51:37 2001 +++ /usr/src/sbin/dump/traverse.c Fri Nov 30 17:36:05 2001 @@ -347,12 +347,15 @@ ip = getino(dp->d_ino); if (TSTINO(dp->d_ino, dumpinomap)) { CLRINO(dp->d_ino, dumpinomap); - CLRINO(dp->d_ino, usedinomap); *tapesize -= blockest(ip); } - /* Add back to dumpdirmap to propagate nodump. */ + /* + * Add back to dumpdirmap and remove from usedinomap + * to propagate nodump. + */ if ((ip->di_mode & IFMT) == IFDIR) { SETINO(dp->d_ino, dumpdirmap); + CLRINO(dp->d_ino, usedinomap); ret |= HASSUBDIRS; } } else { >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message