Hi Bernard,
You've had a few xfsdump/xfsrestore emails of late :)
On Sun, Jul 08, 2001 at 02:21:44PM +0200, Bernhard R. Erdmann wrote:
> I just did some torture testing with xfsdump/xfsrestore (Kernel
> linux-2.4.7-pre3-xfs, checkout 04:30 GMT).
>
> Using a perl script referenced from
> http://reality.sgi.com/zwicky_neu/testdump.doc.html (Torture-testing
> Backup and Archive Programs: Things You Ought to Know But Probably Would
> Rather Not, Elizabeth D. Zwicky, 1991)
>
> I had to modify torture.perl (10 years old) in order to run with a
> modern linux system. You can download it from
> http://berdmann.dyndns.org/torture.tar.gz
>
Sounds interesting - I like the title - I can relate to it
(particularly the "But Probably Would Rather Not" part :)
It sounds a good src of pv's (read that "bug reports") :)
It would also be a good test program for cmd/xfstests.
>
> I gave a filesystem with the "directory from Hell" to xfsdump, but
> xfsrestore fails in content.c to read the directory index:
>
> # ~be/torture-new/torture.perl
> First guess at max component length is 255
> max path length appears to be 4095
> Type a command line which will run a backup program on the dump test
> directory: /sbin/xfsdump -J - /mnt/test1 | (cd
> /mnt/test2/linux-xfsrestore && /sbin/xfsrestore - .)
> Child 1
> /sbin/xfsrestore: version 3.0 - Running single-threaded
> /sbin/xfsrestore: reading directories
> xfsrestore: content.c:2942: applydirdump: Assertion `namelen < 255'
> failed.
>
Okay it looks like xfsdump is happy to dump files with names
>= 255 in length, but xfsrestore is not happy to restore them.
This bug would also occur in IRIX.
I'll post a bug on this in SGI to be fixed.
Thanks for the info.
On Sun, Jul 08, 2001 at 12:41:20PM +0200, Bernhard R. Erdmann wrote:
>
> today I did some restore tests (do you really trust your backups?)
>
> Then I used tar to compare the two directory trees:
>
> # (cd /var/spool/imap && tar cf - .) | tar df -
> [...]
> tar: ./user/be/Sent/xy/290.: Warning: Cannot stat: No such file or
> directory
> [...]
>
> Lots of files were missing (mostly due to reorganisation, aka moving
> mails to different folders). I traced the history of this particular
> file user/be/Sent/xy/290.
>
>
> What did xfsrestore do to my holy IMAP spool???
Don't know - deleted it perhaps :)
>
>
> xfsrestore.debug.3 told me xfsrestore had deleted user/be/Sent/xy/290.:
>
> [...]
> /usr/sbin/xfsrestore: rename nondir user/be/Sent/xy/290. to
> orphanage/9074670.1
> /usr/sbin/xfsrestore: unlink nondir orphanage/9074670.1
> [...]
> /usr/sbin/xfsrestore: restoring user/be/Sent/xy/291. (9074676 0)
> /usr/sbin/xfsrestore: restoring regular file ino 9074676
> user/be/Sent/xy/291.
> /usr/sbin/xfsrestore: truncating user/be/Sent/xy/291. from 0 to 775
> /usr/sbin/xfsrestore: restore complete: 76 seconds elapsed
>
> What's going on here? I'm using xfsdump-1.0.9-0.
It looks like that this is happening in the function
xfsdump/restore/tree.c/proc_hardlinks_cb().
I'm not sure what this code is trying to do !
However, I'll post a bug on this at SGI and
look into it further.
Thanks for the report.
On Sun, Jul 01, 2001 at 06:31:53PM +0200, Bernhard R. Erdmann wrote:
> Hi,
>
> i'm able to lock up xfsrestore when restoring onto a JFS filesystem.
Bummer.
Not likely to be a high priority for us though ;-)
> xfsrestore becomes dead in ps and is unkillable (waiting for I/O to
> happen?):
>
> # /sbin/mkfs.jfs /dev/vg01/usrjfs
> # cd /tmp
> # mount -t jfs /dev/vg01/usrjfs /mnt/usr
> # strace /sbin/xfsrestore -f tmp.xfsd /mnt/usr
> [..bla..]
perspath = open_pathalloc( tranp->t_hkdir, persname, 0 );
tranp->t_persfd = open( perspath,
O_CREAT | O_RDWR,
S_IRUSR | S_IWUSR );
> open("/mnt/usr/xfsrestorehousekeepingdir/state",
> O_RDWR|O_CREAT|O_LARGEFILE, 0600) = 4
persp = ( pers_t * ) mmap_autogrow(perssz, tranp->t_persfd, 0);
mmap_autogrow():
> SYS_197(0x4, 0xbffff990, 0x4010cd40, 0, 0x4) = 0
fstat64()
> _llseek(4, 20479, [20479], SEEK_SET) = 0
> write(4, "\0", 1) = 1
> SYS_192(0, 0x5000, 0x3, 0x1, 0x4) = 1073831936
mmap2()
ownerpr = ( geteuid( ) == 0 ) ? BOOL_TRUE : ownerpr;
> geteuid() = 0
rval = munmap( ( void * )persp, perssz );
> munmap(0x40016000, 20480) = 0
rval = ftruncate( tranp->t_persfd, ( off_t )perssz
+
( off_t )( stpgcnt + descpgcnt )
*
( off_t )pgsz );
> SYS_194(0x4, 0x5000, 0, 0, 0x4
ftruncate64
>
> ...and there it ends.
It looks like it is hanging on line 1606 in a call to ftruncate()
in xfsdump/restore/content.c/content_init().
It can't seem to ftruncate() /mnt/usr/xfsrestorehousekeepingdir/state.
The file gets opened, written to, mapped, unmapped and
then truncated, where it hangs.
I don't know why it is hanging when truncating.
Perhaps you could try a simple test program which does similar
calls as xfsrestore.
I doesn't look like an xfsrestore problem.
Cheers,
Tim.
|