| To: | Justin Piszcz <jpiszcz@xxxxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: XFS CORRUPTION 2.6.17.13? |
| From: | David Chinner <dgc@xxxxxxx> |
| Date: | Fri, 24 Nov 2006 10:55:25 +1100 |
| Cc: | David Chinner <dgc@xxxxxxx>, Russell Cattelan <cattelan@xxxxxxxxxxx>, xfs@xxxxxxxxxxx |
| In-reply-to: | <Pine.LNX.4.64.0611231816340.18083@p34.internal.lan> |
| References: | <Pine.LNX.4.64.0611201459420.17165@p34.internal.lan> <1164231716.19915.68.camel@xenon.msp.redhat.com> <Pine.LNX.4.64.0611231139040.32343@p34.internal.lan> <20061123230744.GA11034@melbourne.sgi.com> <Pine.LNX.4.64.0611231816340.18083@p34.internal.lan> |
| Sender: | xfs-bounce@xxxxxxxxxxx |
| User-agent: | Mutt/1.4.2.1i |
On Thu, Nov 23, 2006 at 06:18:00PM -0500, Justin Piszcz wrote: > Ah, > > I did not make a copy unfortunatley. It was too much to hope for :/ > I used the default mkfs.xfs settings from Knoppix 4.0.2 I believe, > whatever version of xfsprogs it has for a 400GB drive. Ok, so 256 byte inodes then. A single bad buffer write is possible then. > Any idea how it could have been 'trashed' in one way? It appeared to > occur shortly after boot-up, which then a backup occurs (heavy I/O) to a > remote box via NFS. No idea - I was hoping to get a clue by looking at the raw corrupted data if you still had it around..... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: XFS CORRUPTION 2.6.17.13?, Justin Piszcz |
|---|---|
| Next by Date: | Re: [PATCH] (and bad attr2 bug) - pack xfs_sb_t for 64-bit arches, Timothy Shimmin |
| Previous by Thread: | Re: XFS CORRUPTION 2.6.17.13?, Justin Piszcz |
| Next by Thread: | TAKE 956783 - xfs_dm_getall_dmattr() doesn't check if the user buffer is at valid address, Vlad Apostolov |
| Indexes: | [Date] [Thread] [Top] [All Lists] |