Re: stalling

Ryan Lovett <[email protected]> wrote:

> With star 1.5.2 on the latest Solaris 10, we are seeing star appear to
> stall in the middle of dumping a ZFS snapshot to tape. Attaching dtruss,
> iosnoop, and opensnoop to the affected process shows no activity. We
> invoke star with:
>
>   star -C /path/to/.zfs/snapshot/20130407 -c -S -acl artype=3Dexustar \
> 	-sparse -time -xdev \
> 	-multivol -wtardumps -new-volume-script=3D/usr/local/sbin/mtx-next \
> 	errctl=3D/usr/local/etc/star-errctl.conf \
> 	-not pat=3D*/.Trash/* pat=3D*/.cache/* pat=3D*/.thumbnails/* pat=3D*/.nf=
s* \
> 	level=3D0 fs-name=3D/path/to blocks=3D512 file=3D/dev/rmt/1cn .

First a warning: If you exclude parts of the filesystem from a dump, star w=
ill =

not be able to "restore" files that have been brought back into the "visibl=
e" =

parts of the dump by renaming a a directory that was in the excluded part.

This is because such an action does not set the "ctime" stamp on such files.

> I don't believe it is a problem with the tape device since we can kill the
> hanging star and run another (on another filesystem) right after which
> runs to completion.
>
> Does anything above suggest why the star process stalls or waits?
>
> How can one debug this further?

Your current statements do not include any information that could help.

The minimal information would be to run truss on both star processes in ord=
er =

to get the current state of the processes.

I assume that star is not looping, so this should show a syscall...

Also helpful would be a "pstack" outoput from both processes.

How much data did star already dump before stalling?

J=F6rg

-- =

 EMail:[email protected] (home) J=F6rg Schilling D-13353 Be=
rlin
       [email protected]                (uni)  =

       [email protected] (work) Blog: http://schily.blogs=
pot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily