dump warning msgs??
Here is the output messages from a test dump of a live file system / What are the warning messages trying to tell me and more important the expected next file 16454, got 437 message? /mnt dump -0Lauf - /dev/ad0s1a | restore -rf - DUMP: Date of this level 0 dump: Mon Feb 22 21:28:25 2010 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping snapshot of /dev/ad0s1a (/) to standard output DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 171427 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] warning: ./.snap: File exists warning: ./tmp: File exists expected next file 16454, got 437 DUMP: 88.38% done, finished in 0:00 at Mon Feb 22 21:34:06 2010 DUMP: DUMP: 171430 tape blocks DUMP: finished in 343 seconds, throughput 499 KBytes/sec DUMP: level 0 dump on Mon Feb 22 21:28:25 2010 DUMP: DUMP IS DONE # /mnt ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: dump warning msgs??
On Mon, Feb 22, 2010 at 09:48:24PM +0800, Aiza wrote: Here is the output messages from a test dump of a live file system / What are the warning messages trying to tell me and more important the expected next file 16454, got 437 message? Looks like it finished OK. Those numbers are inode identifiers. I don't know the exact algorithm dump uses for sorting the inodes, but this looks like a file was deleted between the time the list was made and the time dump got to reading it. That is a message of the sort it makes when those things happen. jerry /mnt dump -0Lauf - /dev/ad0s1a | restore -rf - DUMP: Date of this level 0 dump: Mon Feb 22 21:28:25 2010 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping snapshot of /dev/ad0s1a (/) to standard output DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 171427 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] warning: ./.snap: File exists warning: ./tmp: File exists expected next file 16454, got 437 DUMP: 88.38% done, finished in 0:00 at Mon Feb 22 21:34:06 2010 DUMP: DUMP: 171430 tape blocks DUMP: finished in 343 seconds, throughput 499 KBytes/sec DUMP: level 0 dump on Mon Feb 22 21:28:25 2010 DUMP: DUMP IS DONE # /mnt ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: dump warning msgs??
On Monday 22 February 2010, Jerry McAllister wrote: I don't know the exact algorithm dump uses for sorting the inodes, but this looks like a file was deleted between the time the list was made and the time dump got to reading it. I expect it's the inode for the temporary snapshot in the .snap directory. According to the man page this snapshot is unlinked as soon as the dump starts. I assume this is immediately after creating the list of inodes to be backed up, in which case it's in the list but no longer available when the data is dumped. I see the expected xxx, got yyy type of message every time I do a restore from a snapshot dump but it's never caused any problems. I've just done a test dump with the -L option and monitored the contents of the partition's .snap directory, a file named dump_snapshot with inode number 4 appeared as I started the dump and then disappeared. I then tried to restore the entire dump to a temporary destination and got a message expected next file 1319089, got 4. As I expected, the .snapshot directory in the dump was empty with no sign of the dump_snapshot file so I'm assuming that restore put out the warning message when it's list of inodes suggested that number 4 should be the next one but the next sequential file in the dump corresponded to inode 1319089. The wording of the message does however suggest that it actually found the file for inode 4 in the dump when the list of inode numbers indicated that the next sequential file should have been 1319089. I was anticipating the message to be expected next file 4, got 1319089 -- Mike Clarke ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: dump warning msgs??
On Mon, 22 Feb 2010 16:37:59 +, Mike Clarke jmc-freeb...@milibyte.co.uk wrote: I see the expected xxx, got yyy type of message every time I do a restore from a snapshot dump but it's never caused any problems. The message is issued by restore, not by dump. According to /usr/src/sbin/restore/restore.c, beginning at line 620, the explaination is: If we find files on the tape that have no corresponding directory entries, then we must have found a file that was created while the dump was in progress. Since we have no name for it, we discard it knowing that it will be on the next incremental tape. This fits the snapshot theory. Use the source, Luke. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: dump warning msgs??
On Monday 22 February 2010, Polytropon wrote:
On Mon, 22 Feb 2010 16:37:59 +, Mike Clarke
jmc-freeb...@milibyte.co.uk wrote:
I see the expected xxx, got yyy type of message every time I do a
restore from a snapshot dump but it's never caused any problems.
The message is issued by restore, not by dump. According
to /usr/src/sbin/restore/restore.c, beginning at line 620,
the explaination is:
If we find files on the tape that have no corresponding
directory entries, then we must have found a file that
was created while the dump was in progress. Since we have
no name for it, we discard it knowing that it will be
on the next incremental tape.
This fits the snapshot theory. Use the source, Luke. :-)
Yes, I was aware that it was a message from restore and not dump but I
misunderstood how it came about. I think I can see part of what's
happening now. At line 367 in /usr/src/sbin/dump/main.c we have
snprintf(snapname, sizeof snapname,
%s/.snap/dump_snapshot, mntpt);
snprintf(snapcmd, sizeof snapcmd, %s %s %s,
_PATH_MKSNAP_FFS, mntpt, snapname);
unlink(snapname);
if (system(snapcmd) != 0)
errx(X_STARTUP, Cannot create %s: %s\n,
snapname, strerror(errno));
if ((diskfd = open(snapname, O_RDONLY)) 0) {
unlink(snapname);
errx(X_STARTUP, Cannot open %s: %s\n,
snapname, strerror(errno));
}
unlink(snapname);
... so when we make a dump of e.g. /home we've set snapcmd to the
string mksnap_ffs /home /home/.snap/dump_snapshot [1] and then
execute it to create a snapshot. We then open the snapshot and
immediately unlink it. Although this effectively deletes the snapshot
file from the working filesystem it still exists in the snapshot of the
system (and would appear in a directory listing of the snapshot if it
were to be mounted somewhere). At this point I'm starting to get lost
because dump will use the opened snapshot to traverse the system and
will see .snap/dump_snapshot when it maps the files and directories so
this file should be included in the dump and appear in its contents
list but somehow it's present in the dump (although truncated to a zero
length file) but not mapped to any name. I don't see anywhere in the
code where .snap/dump_snapshot might receive any special treatment to
exclude it from the file list, but finding my way through unfamiliar
code is something I'm definitely not very skilled at so I've probably
overlooked something really obvious. Although it's not really a problem
I'm rather curious to understand just how dump handles this.
[1] I'm also puzzled by the use of the command
mksnap_ffs /home /home/.snap/dump_snapshot. According to the man page
I'd have expected just mksnap_ffs /home/.snap/dump_snapshot but quick
experiments show that both forms appear to produce the same result?
--
Mike Clarke
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
