| To: | Mark Magpayo <mmagpayo@xxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: Repairing a possibly incomplete xfs_growfs command? |
| From: | David Chinner <dgc@xxxxxxx> |
| Date: | Wed, 23 Jan 2008 08:13:11 +1100 |
| Cc: | xfs@xxxxxxxxxxx |
| In-reply-to: | <9CE70E6ED2C2F64FB5537A2973FA4F0253596D@pvn-3001.purevideo.local> |
| References: | <9CE70E6ED2C2F64FB5537A2973FA4F0253595A@pvn-3001.purevideo.local> <20080117234604.GG155407@sgi.com> <9CE70E6ED2C2F64FB5537A2973FA4F0253595B@pvn-3001.purevideo.local> <20080119004018.GH155407@sgi.com> <9CE70E6ED2C2F64FB5537A2973FA4F0253596D@pvn-3001.purevideo.local> |
| Sender: | xfs-bounce@xxxxxxxxxxx |
| User-agent: | Mutt/1.4.2.1i |
On Tue, Jan 22, 2008 at 11:40:52AM -0800, Mark Magpayo wrote: > 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? Yes, it can if it's swapping like mad because you don't have enough RAM in the machine. Runtime is also detemrined by how many inodes there are in the filesystem - do you know how many there are? Also, more recent xfs_repair versions tend to be faster - what version are you using again? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group |
| Previous by Date: | Re: blktrace & btrace usability, Linda Walsh |
|---|---|
| Next by Date: | RE: Repairing a possibly incomplete xfs_growfs command?, Mark Magpayo |
| Previous by Thread: | RE: Repairing a possibly incomplete xfs_growfs command?, Mark Magpayo |
| Next by Thread: | RE: Repairing a possibly incomplete xfs_growfs command?, Mark Magpayo |
| Indexes: | [Date] [Thread] [Top] [All Lists] |