I just started getting these on an ext3 filesystem also on gentoo, with the latest stable kernel. I suspect there is an lvm bug of some kind that is responsible. I ran an e2fsck on the filesystem and
I just started getting these on an ext3 filesystem also on gentoo, with the latest stable kernel. I suspect there is an lvm bug of some kind that is responsible. I ran an e2fsck on the filesystem and
I'm still seeing a lot of the following in my dmesg. Any ideas? See below for what I have already tried (including moving data to a fresh XFS volume). Tons of these; sometimes the want= changes, but
I'm still seeing a lot of the following in my dmesg. Any ideas? See below for what I have already tried (including moving data to a fresh XFS volume). Tons of these; sometimes the want= changes, but
I'm still seeing problems. =( Most recently I have copied all of the data off of the suspect XFS volume onto another fresh XFS volume. A few days later I saw the same messages show up in dmesg. I hav
I'm still seeing problems. =( Most recently I have copied all of the data off of the suspect XFS volume onto another fresh XFS volume. A few days later I saw the same messages show up in dmesg. I hav
I have an XFS filesystem that has had the following happen twice in 3 months, both times with an impossibly large block number was requested. Unfortunately my logs don't go back far enough for me to
Jay Sullivan wrote: I ran xfs_repair -L on the FS and it could be mounted again, Was it not even mountable before this, or why did you use the -L flag? If the log is corrupted that points to more pro
Good eye: it wasn't mountable, thus the -L flag. No recent (unplanned) power outages. The machine and the array that holds the disks are both on serious batteries/UPS and the array's cache batteries
Did you have the xfs_repair output to see what it found? You might also grab the very latest xfsprogs (2.9.4) in case it's catching more cases. I hate it when people suggest running memtest86, but I
(Sorry if this is a dupe to the list; it has been a long day.) I have an XFS filesystem that has had the following happen twice in 3 months, both times an impossibly large block number was requested.
Eric Sandeen wrote: Jay Sullivan wrote: I ran xfs_repair -L on the FS and it could be mounted again, Was it not even mountable before this, or why did you use the -L flag? If the log is corrupted tha
.... Sure sign of a corrupted btree. <shrug> What was the problem that xfs_repair fixed? BTW, why did you run xfs_repair -L? Also, when it happens next, what does xfs_check tell you is broken? Cheers
I lost the xfs_repair output on an xterm with only four lines of scrollback... I'll definitely be more careful to preserve more 'evidence' next time. =( "Pics or it didn't happen", right? I just upgr
What can I say about Murphy and his silly laws? I just had a drive fail on my array. I wonder if this is the root of my problems... Yay parity. ~Jay I lost the xfs_repair output on an xterm with only
maybe none, it was just a wild guess. :) I've seen a bug on ext3, volumes > 2T corrupted, on an areca controller. Due to the 2T threshold, it seems more like a lower layer IO issue (2^32 x 512) than
Of course this had to happen one more time before my scheduled maintenance window... Anyways, here's all of the good stuff I collected. Can anyone make sense of it? Oh, and I upgraded to xfsprogs 2.9
Forgot to ask, are you running w/ 4k stacks? And/or, do you have stack usage debugging enabled? That's quite a backtrace you've got there... just a shot in the dark. -Eric
I have an XFS filesystem that has had the following happen twice in 3 months, both times with an impossibly large block number was requested. Unfortunately my logs don't go back far enough for me to