enami tsugutomo <enami@sm.sony.co.jp>  wrote:
 > > With some debug statements Herb and I found that when the XXX line was
 > > reached:
 > > 	first=2642949
 > > 	last=4291799
 > > 	curfile.ino=11198465
 > 
 > What's your filesystem's ipg (number of inode per cg) and ncg (number
 > of cg)?  You can see this value by ``dumpfs /dev/rraid1a | more''.  If
 > ipg * ngp become 11198466, restore may be looking TS_END block.

ncg     10929   ncyl    2797796 size    44764736        blocks  43190773
cpg     256     bpg     512     fpg     4096    ipg     1024

 > > 	maxino=11190290
 > 
 > I wonder how restore calculate this.  I can't believe this can be
 > calculate by (spcl.c_count * TP_BSIZE * NBBY) + 1.
 > 
 > > Note that curfile.ino is greater than maxino, which probably isn't
 > > supposed to happen.  Dump is apparently dumping a file with an
 > > inode greater than the maximum given in the dump header.  Could this
 > > be caused by a file created in between the directory traversal and
 > > file dumping? perhaps the temp file created by restore in /tmp?
 > 
 > So, your /tmp is on a same filesystem with you're dumping?

that's correct.

When I built the system, I was feeling too lazy to figure out how
I wanted to subdivide everything so I chose "one big partition".
I know probably stupid but......