Herb Peyerl <hpeyerl@beer.org> writes:

> 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

Hm, so in dump(8),
maxino is (* 10929 1024) => 11191296
mapsize is (* (/ (+ (/ (+ 11191296 7) 8) 1023) 1024) 1024) => 1399808
c_count for bitmap is (/ (+ 1399808 1023) 1024) => 1367

So, maxino in restore(8) is (+ (* 1367 1024 8) 1) => 11198465

>  > > 	curfile.ino=11198465

So, it looks like restore reading TS_END block.

# I was wrong in my previous mail.  c_inumber in TS_END may be
# 11191295 but curfile.ino is maxino in restore.

But still i'm not sure...

>  > > 	maxino=11190290

... where this value came from.

And also wondering how many files exits in this range:

>  > > 	first=2642949
>  > > 	last=4291799

Anyway, my current guess is the file with highest inode number was
deleted before is dumped to tape and restore fails to handle it.

enami.