Hi,
Another thing that may be helpful is some debugging output for restore.
The verbose option of -v5 gives useful stuff.
However, on large restores it may produce annoyingly large output.
If the output is too large then it may be helpful to turn on debugging
at a particular point in the code using mlog_override_level().
For example,
to turn on debugging just prior to the "directory post-processing":
$ p_rdiff -u content.c
--- xfsdump/restore/content.c_1.32 2004-03-23 12:06:43.000000000 +1100
+++ xfsdump/restore/content.c 2004-03-23 12:00:15.000000000 +1100
@@ -2343,6 +2343,7 @@
mlog( MLOG_VERBOSE, _(
"directory post-processing\n") );
win_locks_off(); /* we are single threaded here */
+mlog_override_level(5);
rv = treepost( path1, path2 );
win_locks_on();
switch ( rv ) {
--Tim
On Mon, Mar 22, 2004 at 04:40:55PM -0600, Mandy Kirkconnell wrote:
> Nathan Scott wrote:
> > On Sun, Mar 21, 2004 at 10:42:33PM -0500, Jason Parker-Burlingham wrote:
> >
> >>I'm running a 2.4.23 kernel from CVS with LVM1 patches applied. I'm
> >>trying to move an XFS filesystem from one logical volume to another
> >>using xfsrestore 2.2.18 and not having a lot of success:
> >>
> >> # xfsdump -J - /mnt | xfsrestore -J - /pivot
> >> [...]
> >> xfsrestore: reading directories
> >> xfsdump: dumping non-directory files
> >> xfsrestore: 2694 directories and 69903 entries processed
> >> xfsrestore: directory post-processing
> >> xfsrestore: WARNING: mkdir failed: No such file or directory
> >> xfsrestore: WARNING: mkdir failed: No such file or directory
> >> xfsrestore: WARNING: mkdir failed: No such file or directory
> >> xfsrestore: WARNING: mkdir failed: No such file or directory
> >> xfsrestore: WARNING: unable to set non-root extended attribute for : No
> >> such file or directory (2)
> >> xfsrestore: WARNING: unable to set secure extended attribute for : No
> >> such file or directory (2)
> >> xfsrestore: restoring non-directory files
> >> xfsrestore: WARNING: open of ///gconf.xml.defaults/schemas///UI/ failed:
> >> No such file or directory: discarding ino 135
> >> [...]
> >> xfsrestore: WARNING: open of /Kodak Pictures// failed: Is a directory:
> >> discarding ino 10811
> >>
> >>The point at which the errors occur does not appear to be repeatable.
> >>
> >>If I let the dump/restore run to completion, xfsrestore reports
> >>success and the filesystem appears to be complete, but directory
> >>permissions are set to 000.
> >>
> >>Is there some other option I should be passing to xfsrestore?
> >
> >
> > Don't think so, looks like a bug. Almost looks like the filename
> > string is null for some reason, somewhere in restore (those mkdir
> > errors, etc, above - look like they're trying to print filenames).
> >
> > Does this ring any bells Mandy?
>
> No, this is new to me. I agree that it looks like there are a bunch of
> null filename strings. Jason, you mentioned that the point of error
> doesn't seem to be consistent but it sounds like it's reproducible in
> the sense that you've seen this behaviour more than once. Is there
> anything unique or special about the data you're restoring? It looks
> like the FS may have extended attributes (non-root, secure, or both ??).
> I haven't been able to repro this yet so any additional info would be
> helpful.
>
> Mandy
>
|