On Sat, 2012-01-14 at 13:58 -0600, Jonathan Nieder wrote: > Jonathan Nieder wrote: > > > Interesting. So this might be a case of the kernel not coping well > > with previous filesystem corruption. > > Some reading: [1] > > >From similar symptoms at [2]: > > | This indicates filesystem corruption, which may be caused by a hardware/media > | fault. > | > | I suggest you run xfs_repair and then xfs_db to dump any inodes that may have > | problems. > | > | Also check smartctl, dmesg etc for any hardware errors. > | > | This class of fault is typically very hard to track down, the corruption > | (whether caused by software or hardware) may have happened a week ago and > | its only now you have read that part of the filesystem again. > > Apparently one cause of this in olden days was [3] (probably not > what's happening here, since that got fixed a while ago). Another was > running with write cache enabled but without barriers which didn't > work over the device mapper. > > In any case, I think reporting "XFS internal error" rather than > something more enlightening like "magic number is wrong - filesystem > is probably corrupt" is a bug in itself. So it would be nice to > figure out what happened and at least fix this that much. [...] Also, filesystems should generally be considered untrusted data and therefore the possibility for a corrupted filesystem to trigger a crash can be considered a security vulnerability. The XFS developers would probably be interested to know about it even if the corruption itself is due to a hardware fault. Ben. -- Ben Hutchings When in doubt, use brute force. - Ken Thompson
Attachment:
signature.asc
Description: This is a digitally signed message part