Date: Mon, 9 Jul 2001 15:54:29 +1000
From: Timothy Shimmin <tes@boing.melbourne.sgi.com>
To: "Bernhard R. Erdmann" <be@berdmann.de>
Cc: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Re: xfsdump/xfsrestore fails Zwicky's torture test
Message-ID: <20010709155428.C11622@boing.melbourne.sgi.com>
References: <3B3F5079.F1776C04@berdmann.de> <3B4838D0.5BAEDF4F@berdmann.de> <3B485058.9389834C@berdmann.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <3B485058.9389834C@berdmann.de>; from be@berdmann.de on Sun, Jul 08, 2001 at 02:21:44PM +0200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

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.