Solaris 10 - ufsdump hangs

Anyone ever see an issue where ufsdump 'hangs' after the IV Pass?
Normally, it will update with an estimate of how long it will take to complete...and update the info every 20 minutes.

I'm running the following command:

root# ufsdump 0f - /fsmount | ( cd /zfs/newfsmount ) ; ufsrestore rf - )

(we are moving from UFS to ZFS - on Solaris 10!)

I've got 2 UFS file systems that just won't work with ufsdump. I've run fsck with no issues found, ran the ufsdump while mounted (apps and database down), ran it while it was mounted read-only (with apps and database down), ran it while file system was unmounted (with apps and database down). Nothing works.

Yet I'm using ufsdump on more than 10 other UFS file systems with no issue.

No error messages from ufsdump, nothing in messages file...

DUMP: Date of this level 0 dump: Sat Sept 27 14:16:16 2014
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/rdsk/c14t600015D000236B00000340200111052Cd0s2 (server004:/fsmount) to standard output.
DUMP: Mapping (Pass I) [regular files]
DUMP: Mapping (Pass II) [directories]
DUMP: Writing 32 Kilobyte records
DUMP: Estimated 441443448 blocks (215548.56 MB).
DUMP: Dumping (Pass III) [directories]
DUMP: Dumping (Pass IV) [regular files]
(this is where it should update with how long it will take...but I get nothing...left it running for 12 hours and still nothing)

If I control-C the dump, it ask if I want to abort...last night was the first time I said no. It finally started showing/updating the status...
DUMP: 0.12% done, finished in 19962:24

It continued showing updates until completed - but it never copied one file! It did create some of the directories on the new disk (13 of the 99 top directories)
and a total of 382 directories, but NO data, ascii, text, non-directory files.

Solaris 10 1/3 - generic 147147-26

One of them I finally ran tar against to get the copy completed - with no issues.
The last one I'll have to do the same but it will take a whole weekend to complete. FS is only 504G (where I've had 2TB FS convert with ufsdump with no issues). Plenty of free space, plenty of free memory, no issues with inodes on old UFS FS, new ZFS pool has enough space....

Hopefully someone has seen this before and knows what it is...thanks!

So you're running ufsdump without fssnap to snapshot first?

Perhaps it's coming across what it thinks are open/locked files.

You should run fssnap first and then dump the special (static) device fssnap gives you.

Also, remember to delete the snapshot (again using fssnap) once the ufsdump has completed.

Failing that I'd be tempted to fully check the filesystem with

# fsck -o full

option. It will take a long time but will check everything on the filesystem. Of course, yes, it might be quicker to resort to tar but will that give you a faithfull restore of the filesystem?

Search this forum for threads about ufsdump AND fssnap. I've written about all this before on this forum.

What does "iostat -E" show?

What's in /var/adm/messages?

What does a pstack of the running ufsdump process show?

What does running ufsdump under "truss -f -a -vall -o /path/to/output/file ..." show?