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). 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. 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
State Changed From-To: open->closed Committed. Thanks!
Responsible Changed From-To: freebsd-bugs->obrien I did the commit.
On Wed, Dec 05, 2001 at 02:46:37PM -0800, David O'Brien wrote: > On Wed, Dec 05, 2001 at 02:19:18PM -0800, Crist J . Clark wrote: > > > > Are you planning to MFC? There was no 'MFC after' in the commit > > message, > > I don't believe in "MFC after". > I need to see this spend more time in -current before I consider an MFC > of it myself. Others are free to MFC it if they like. (though I > wouldn't mind an email besides the commit message letting me know when > they've done it) > Then please re-open this PR in the `feedback' state. Otherwise, we're likely to receive a duplicate PR (the original one was for 4.4-STABLE). [...] Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age
i just ran into this bug on 4.8. if nobody found any problems with the patch in the last 1.5 years, it is probably ready for mfc.