Messages in this thread | | | Date | Fri, 21 Sep 2007 04:48:07 -0400 (EDT) | From | Justin Piszcz <> | Subject | Re: 2.6.20 (XFS? related) crash after uptime of > 180 days during apt-get dist-upgrade on Debian Testing |
| |
On Fri, 21 Sep 2007, David Chinner wrote:
> On Wed, Sep 19, 2007 at 04:47:38AM -0400, Justin Piszcz wrote: >> On Mon, 17 Sep 2007, Justin Piszcz wrote: >> >>> Including the XFS mailing list in here too because it may be an XFS bug >>> looking at the call trace. >>> >>> System: Debian Testing >>> Kernel: 2.6.20 >>> Config: Attached >>> >>> I was running apt-get dist-upgrade as I always do to get the latest >>> packages upgraded and the kernel OOPS'd when it was upgrading 'tzdata' and >>> the process went into D-state and I had to reboot. >>> >>> The config file is from 2.6.20 but it had been moved to a 2.6.22 directory >>> for an upgrade, but all of the options have been left unchanged. >>> >>> Here is the *OOPS I captured via dmesg before I rebooted: >>> >>> >> >> Also, >> >> Not sure if this helps but when this happened, any file that was open() >> for read/write seem to have also been corrupted.. > > Is that all files, or just ones that were being changed? It is the only one I noticed because another program depended upon it being not-corrupt.
> >> $ /usr/sbin/xfs_bmap -v myconfig.txt.orig >> myconfig.txt.orig: >> EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL >> 0: [0..7]: 64601112..64601119 14 (52040..52047) 8 >> $ /usr/sbin/xfs_bmap -v myconfig.txt >> myconfig.txt: >> EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL >> 0: [0..7]: 64625720..64625727 14 (76648..76655) 8 >> $ md5sum myconfig* >> db8c50ca2c86d2e757ecef1d6b3fcc69 myconfig.txt >> 09fb630623b3ae614511cef4c7a21063 myconfig.txt.orig >> $ file myconfig.txt myconfig.txt.orig >> myconfig.txt: ASCII text >> myconfig.txt.orig: data >> $ >> >> $ strings -a myconfig.txt.orig >> $ >> >> $ od -c myconfig.txt.orig >> 0000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * >> 0003500 \0 \0 \0 \0 \0 \0 >> 0003506 >> >> Seems like it was NULL'd out? > > A single block of zeros - its possible that the crash occurred between > the allocation transaction and the data write - the allocation gets > replayed (along with the new file size), but the data write does > not (not journalled). This is one of the rarer "NULL files on crash" > failure modes fixed in 6.5.22..... > > Cheers, > > Dave. > -- > Dave Chinner > Principal Engineer > SGI Australian Software Group > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |