Date: Mon, 6 Aug 2007 11:28:01 -0400 From: Bill Moran <wmoran@potentialtech.com> To: Jerry McAllister <jerrymc@msu.edu> Cc: User Questions <freebsd-questions@freebsd.org>, Victor Sudakov <sudakov@sibptus.tomsk.ru> Subject: Re: dump -L Message-ID: <20070806112801.986d8609.wmoran@potentialtech.com> In-Reply-To: <20070806145726.GA64755@gizmo.acns.msu.edu> References: <20070724115401.GA1355@admin.sibptus.tomsk.ru> <20070806025614.GA21368@admin.sibptus.tomsk.ru> <20070806145726.GA64755@gizmo.acns.msu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
In response to Jerry McAllister <jerrymc@msu.edu>: > On Mon, Aug 06, 2007 at 09:56:15AM +0700, Victor Sudakov wrote: > > > Victor Sudakov wrote: > > > > > > I always use "dump -L" to dump a live filesystem. > > > However, when I restore the dump, I sometimes get messages like > > > "foo.txt (inode 12345) not found on tape" or > > > "expected next file 12345, got 23456" > > > > > > I thought this should _never_ happen when dumping a snapshot. > > > > > > What is it? > > > > Does nobody know the answer, or am I the only one experiencing the > > problem? > > > > Here is another example: > > > > [root@big ~] restore -b64 -rN > > ./spool/samba.lock/wins.dat: (inode 2829098) not found on tape > > expected next file 267, got 4 > > expected next file 2828988, got 2828987 > > Using 'dump -L' doesn't prevent you or something running on the system > from deleting a file after the directory has been created and written. > > The first thing dump does is create a list of files (including directories) > to dump. It creates a list of inodes for the files and then does all > the dumping from that list of inodes. If a file is then deleted after > that inode list is made, then it will not get written to the dump media. > But, the list will still have the inode for the file. When restore > looks for files, it searches in inode order and makes a note if an > inode is missing from the media that it expected (because of the list) to > be there. It is only a true error if that file really should have been > there and wasn't. The only time I have had that happen was when the > media (tape) couldn't be read properly. Usually then you also get > other errors. Ok, but using -L causes dump to create a filesystem snapshot, which is read- only, meaning that nobody can delete a file from it during the dump process. My guess would be that something is causing the snapshot to fail, which will cause dump to issue a warning and then continue without making a snapshot. Can you provide the output of dump while doing the dump? -- Bill Moran http://www.potentialtech.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070806112801.986d8609.wmoran>