Date: Mon, 22 Feb 2010 22:06:15 +0000 From: Mike Clarke <jmc-freebsd2@milibyte.co.uk> To: freebsd-questions@freebsd.org Cc: Polytropon <freebsd@edvax.de> Subject: Re: dump warning msgs?? Message-ID: <201002222206.15232.jmc-freebsd2@milibyte.co.uk> In-Reply-To: <20100222175616.79f535a0.freebsd@edvax.de> References: <4B828B28.9020703@comclark.com> <201002221638.00165.jmc-freebsd2@milibyte.co.uk> <20100222175616.79f535a0.freebsd@edvax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 22 February 2010, Polytropon wrote: > On Mon, 22 Feb 2010 16:37:59 +0000, Mike Clarke <jmc-freebsd2@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201002222206.15232.jmc-freebsd2>