RE: Repairing a possibly incomplete xfs_growfs command?

["Mark Magpayo" <mmagpayo@xxxxxxxxxxxxx>]

> -----Original Message-----
> From: David Chinner [mailto:dgc@xxxxxxx]
> Sent: Friday, January 18, 2008 4:40 PM
> To: Mark Magpayo
> Cc: David Chinner; xfs@xxxxxxxxxxx
> Subject: Re: Repairing a possibly incomplete xfs_growfs command?
> 
> On Fri, Jan 18, 2008 at 09:50:37AM -0800, Mark Magpayo wrote:
> > > > So is this all I need then prior to an xfs_repair?:
> > > >
> > > > > # for i in `seq 0 1 63`; do
> > > > > > xfs_db -x -c "sb $i" -c 'write agcount 64' -c 'write dblock
> > > 4761733120'
> > > > > /dev/vg0/lv0
> > >
> > > Yes, I think that is all that is necessary (that+repair was what
fixed
> > > the problem at the customer site successfully).
> > >
> >
> > Is this supposed to be the proper output to the command above?
> >
> > purenas:~# for i in `seq 0 1 63`; do xfs_db -x -c "sb $i" -c 'write
> > agcount 64' -c 'write dblock 4761733120' /dev/vg0/lv0; done
> > agcount = 64
> > field dblock not found
> > parsing error
> 
> Ah - As eric pointed out, that should be "dblocks".
> 
> Cheers,
> 
> Dave.
> --
> Dave Chinner
> Principal Engineer
> SGI Australian Software Group

Any ideas on how long the xfs_repair is supposed to take on 18TB?  I
started it Friday nite, and it's now Tuesday afternoon.  It's stuck
here:

Phase 5 - rebuild AG headers and trees...
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - traversing filesystem ...

I figure traversing a filesystem of 18TB takes a while, but does 4 days
sound right?

Thanks,

Mark