| To: | Eric Sandeen <sandeen@xxxxxxx> |
|---|---|
| Subject: | Re: xfs_repair trouble |
| From: | Ragnar Kjørstad <xfs@xxxxxxxxxxxxxxxxxxx> |
| Date: | Tue, 7 May 2002 21:34:07 +0200 |
| Cc: | Willi.Langenberger@xxxxxxxxxxxxx, linux-xfs@xxxxxxxxxxx, kevin@xxxxxxxxxxxxxx |
| In-reply-to: | <1020787090.24935.45.camel@xxxxxxxxxxxxxxxxxxxxxx>; from sandeen@xxxxxxx on Tue, May 07, 2002 at 10:58:10AM -0500 |
| References: | <20020507001545.G18743@xxxxxxxxxxx> <15575.57022.571520.335291@xxxxxxxxxxxxxxxxxxx> <20020507171600.P18743@xxxxxxxxxxx> <1020787090.24935.45.camel@xxxxxxxxxxxxxxxxxxxxxx> |
| Sender: | owner-linux-xfs@xxxxxxxxxxx |
| User-agent: | Mutt/1.2.5.1i |
On Tue, May 07, 2002 at 10:58:10AM -0500, Eric Sandeen wrote: > Hm, looks like log code error handling in general still needs some > scrutiny... I have to work my way out from under some internal > deadlines, and then I can start to look at this. Thanks. Is there something we can test in the meantime to get our filesystem back? I was thinking of commenting out the zero_log() part of xfs_repair to get it to run the rest of the process. Is that safe? Will the filesystem mount afterwards? Or is there a different (better) way to get the repair going? Also; if we can work-around this problem, is there some data we should extract from the filesystem first if you wish to debug the problem later? We already sent the superblock, but if there are other data that might be useful we'll copy that off before doing anything to the filesystem. -- Ragnar Kjørstad Big Storage |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | [Fwd: opinion on XFS], Jeff Layton |
|---|---|
| Next by Date: | Re: Maximum Volume size for XFS on Linux, Seth Mos |
| Previous by Thread: | Re: xfs_repair trouble, Eric Sandeen |
| Next by Thread: | Re: xfs_repair trouble, Stephen Lord |
| Indexes: | [Date] [Thread] [Top] [All Lists] |