| To: | Eric Sandeen <sandeen@xxxxxxxxxxx> |
|---|---|
| Subject: | Re: XFS filesystem corruption on the arm(el) architecture |
| From: | Martin Michlmayr <tbm@xxxxxxxxxx> |
| Date: | Fri, 17 Oct 2008 09:01:09 +0200 |
| Cc: | Tobias Frost <tobi@xxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, debian-arm@xxxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx |
| In-reply-to: | <48F7BC9F.4080909@xxxxxxxxxxx> |
| References: | <1222893502.5020.40.camel@moria> <20081002004556.GB30001@disturbed> <48E4213E.9090508@xxxxxxxxxxx> <20081016212500.GA27228@xxxxxxxxxxxxxxxxxxxxxx> <48F7BC9F.4080909@xxxxxxxxxxx> |
| User-agent: | Mutt/1.5.18 (2008-05-17) |
* Eric Sandeen <sandeen@xxxxxxxxxxx> [2008-10-16 17:13]: > So is this a regression? did it used to work? If so, when? :) The original report was with 2.6.18 but that was with the old ABI: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=423562 I just installed a 2.6.22 kernel with EABI and I can also trigger the bug. So it's not a (recent) regression. > What's a little odd is that the buffer it dumped out looks like the > beginning of a perfectly valid superblock for your filesystem > (magic, block size, and block count all match). If you printk the > "bno" variable right around line 2106 in xfs_da_btree.c, can you see > what you get? bno is 0. > creating an xfs_metadump of the filesystem for examination on a > non-arm box might also be interesting. http://www.cyrius.com/tmp/dump5 (11 MB) -- Martin Michlmayr http://www.cyrius.com/ |
| Previous by Date: | git tree updates...., Dave Chinner |
|---|---|
| Next by Date: | Re: XFS filesystem corruption on the arm(el) architecture, Gaudenz Steinlin |
| Previous by Thread: | Re: XFS filesystem corruption on the arm(el) architecture, Eric Sandeen |
| Next by Thread: | Re: XFS filesystem corruption on the arm(el) architecture, Gaudenz Steinlin |
| Indexes: | [Date] [Thread] [Top] [All Lists] |