Since I was having problems with mandrake's standard kernel (since I
installed 9.0 I had a lot of lock ups -- maybe these are the cause of
the filesystem corruption I'm seeing now), I was compiling stock 2.4.19
kernel + xfs patches (all my filesystems are xfs).
Then I saw a strange compilation error: gcc was telling it wasn't
recognizing the format of a .o file it just compiled. I looked at the
file and in effect it was full of null (0) characters (this is a
phenomenon --files full of null-- I experienced before, BTW, but didn't
give it too much importance).
So I restarted the compile process, but while untarring the kernel
source, tar told me it encountered a premature end of file. An "ls" told
me that there were no files! Heck, all /home files had gone!
Checked the log file and I saw this scary message:

kernel: xfs_force_shutdown(ide0(3,8),0x8) called from line 1039 of file xfs_trans.c. Return address = 0xd08664f2
kernel: Corruption of in-memory data detected. Shutting down filesystem: ide0(3,8)
kernel: Please umount the filesystem, and rectify the problem(s)


Since it was impossible to unmount (strange) and I cannot reboot to
single user mode (I'm diagnosing this remotely), I forced a normal reboot.
After the reboot the /home files were there (pheew), but /home was still
impossible to unmount:

# LANG= LANGUAGE= umount /home
umount: /home: device is busy

# fuser -v /home

USER PID ACCESS COMMAND
/home root kernel mount /home


I remounted it readonly to xfs_check it.
xfs_check gave an endless sequence of messages like

block 7/1006790241 out of range

(that isn't documented in the xfs_check manpage).
After a while I stopped it, and decided to start a xfsdump, so that when
I go home and can do an xfs_repair at least I have a backup (yes, I *do*
have a backup, but it's old and I'd like to avoid to use it).
xfsdump stopped immediately:

xfsdump: level 0 dump of pippo.ventoso.org:/home
xfsdump: dump date: Fri Nov 15 11:11:02 2002
xfsdump: session id: c6eae024-9cfe-486c-9d2d-4ca0316ffcbb
xfsdump: session label: "pippo"
xfsdump: ino map phase 1: skipping (no subtrees specified)
xfsdump: ino map phase 2: constructing initial dump list
xfsdump: WARNING: failed to get bulkstat information for inode 43893388
xfsdump: syssgi( SGI_FS_BULKSTAT ) on fsroot failed: Input/output error
xfsdump: Dump Status: ERROR

and in the log these message again:


kernel: xfs_inotobp: xfs_imap() returned an error 22 on ide0(3,8). Returning error.
kernel: xfs_iunlink_remove: xfs_inotobp() returned an error 22 on ide0(3,8). Returning error.
kernel: xfs_inactive: xfs_ifree() returned an error = 22 on ide0(3,8)
kernel: xfs_force_shutdown(ide0(3,8),0x1) called from line 1952 of file xfs_vnodeops.c. Return address = 0xd086ccf9
kernel: I/O Error Detected. Shutting down filesystem: ide0(3,8)
kernel: Please umount the filesystem, and rectify the problem(s)


the filesystem is still unmountable though.
Frightened, I forced another reboot and made a cp -a of the /home
directory to another partition (after remounting it read only) and,
surprisingly, it worked (but I suspect many files there are corrupted,
didn't have the time to check yet).
Tonigh when I go home I'll see if the xfs_restore works or if it will
trash the filesystem.
Anyway, am I the only one having issues with this kernel?
Is a coincidence that these problems started when upgrading to mdk 9.0?
Xfs support is not stable/tested enough?
Should I swicth to ext3?
Thoughts, suggestions?

I also suspected a memory failure somewhere (too many kernel freezes
that no other have reported made me suspicious), but just yesterday I
ran memtest and gave no errors.

TIA
--
Luca Olivetti
Note.- This message reached you today, it may not tomorrow if you
are using MAPS services. They arbitrarily include in their lists
IP addresses not related in any way to spam, and in so doing are
disrupting Internet connectivity. Please stop supporting them.
See http://slashdot.org/article.pl?sid=01/05/21/1944247


Want to buy your Pack or Services from MandrakeSoft? 
Go to http://www.mandrakestore.com


Reply via email to