> -----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
> > > 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".
> 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
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