From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2smp i686; en-US; rv:0.9.1) Gecko/20010622 Description of problem: I have a Linux box here which has been running for some time now. It's used for compilations, etc.. The problem I am having is that it seems that / is full but isn't really. Here is some info about the machine: Red Hat Linux release 7.1 (Seawolf) Linux linuxserver 2.4.2-2smp #1 SMP Sun Apr 8 20:21:34 EDT 2001 i686 unknown df -k -F ext2 Filesystem 1k-blocks Used Available Use% Mounted on /dev/sda6 1035660 983060 0 100% / /dev/sda2 23333 11489 10640 52% /boot /dev/sda10 48030308 394816 45195624 1% /disk/1 /dev/sda5 2071384 1065004 901156 55% /usr /dev/sda9 256667 4346 239069 2% /usr/local /dev/sda8 256667 25644 217771 11% /var As you can see, / is 100% full. However when you do a du on all the directories it doesn't look like it's anywhere near full. It's a one Gig partition. It shouldn't even be using half that. I have started the system in single user mode and unmounted all partitions in case there is anything hiding anywhere but I could not find anything. I did have a look at the messages file to see if I had any "File system full" messages. I didn't see any, but I did see this: Sep 11 14:56:16 linuxserver kernel: kernel BUG at inode.c:384! Sep 11 14:56:16 linuxserver kernel: invalid operand: 0000 Sep 11 14:56:16 linuxserver kernel: CPU: 0 Sep 11 14:56:16 linuxserver kernel: EIP: 0010:[clear_inode+130/384] Sep 11 14:56:16 linuxserver kernel: EIP: 0010:[<c0150402>] Sep 11 14:56:16 linuxserver kernel: EFLAGS: 00010286 Sep 11 14:56:16 linuxserver kernel: eax: 0000001b ebx: 00000000 ecx: 00000002 edx: 04000000 Sep 11 14:56:16 linuxserver kernel: esi: eebebd80 edi: f0f21424 ebp: ef31ddec esp: ef31dd8c Sep 11 14:56:16 linuxserver kernel: ds: 0018 es: 0018 ss: 0018 Sep 11 14:56:16 linuxserver kernel: Process ps (pid: 3437, stackpage=ef31d000) Sep 11 14:56:16 linuxserver kernel: Stack: c0230d7b c0230e9e 00000180 f8941180 f0f21424 f890d26c eebebd80 eebebd80 Sep 11 14:56:16 linuxserver kernel: f8941180 c0150ef2 eebebd80 f7b13460 ef31ddec f89135b3 f0f21424 00000000 Sep 11 14:56:16 linuxserver kernel: ef31de88 f8930cdd eebebd80 3a699d00 ef31de3c f890a37c 00000002 eebebd80 Sep 11 14:56:16 linuxserver kernel: Call Trace: [error_table+60707/64248] [error_table+60998/64248] [megaraid:mega_hbas+1012160/88211088] +[megaraid:mega_hbas+799404/88423844] [megaraid:mega_hbas+1012160/88211088] [iput+354/368] [megaraid:mega_hbas+824819/88398429] Sep 11 14:56:16 linuxserver kernel: Call Trace: [<c0230d7b>] [<c0230e9e>] [<f8941180>] [<f890d26c>] [<f8941180>] [<c0150ef2>] [<f89135b3>] Sep 11 14:56:16 linuxserver kernel: [megaraid:mega_hbas+945437/88277811] [megaraid:mega_hbas+787388/88435860] [megaraid:mega_hbas+787433/88435815] +[megaraid:mega_hbas+947916/88275332] [megaraid:mega_hbas+925630/88297618] [megaraid:mega_hbas+925473/88297775] [megaraid:mega_hbas+819240/88404008] +[megaraid:mega_hbas+819164/88404084] Sep 11 14:56:16 linuxserver kernel: [<f8930cdd>] [<f890a37c>] [<f890a3a9>] [<f893168c>] [<f892bf7e>] [<f892bee1>] [<f8911fe8>] [<f8911f9c>] Sep 11 14:56:16 linuxserver kernel: [megaraid:mega_hbas+819144/88404104] [megaraid:mega_hbas+926307/88296941] [cached_lookup+45/80] [path_walk+674/2432] +[dput+59/416] [open_namei+144/1808] [filp_open+54/96] [getname+91/160] Sep 11 14:56:16 linuxserver kernel: [<f8911f88>] [<f892c223>] [<c01459ed>] [<c0145f42>] [<c014e8cb>] [<c0146d60>] [<c0139ae6>] [<c01456fb>] Sep 11 14:56:16 linuxserver kernel: [sys_open+58/224] [system_call+51/56] Sep 11 14:56:16 linuxserver kernel: [<c0139dfa>] [<c01091cb>] Sep 11 14:56:16 linuxserver kernel: Sep 11 14:56:16 linuxserver kernel: Code: 0f 0b 8b 86 f8 00 00 00 83 c4 0c 83 e0 08 74 07 56 e8 98 f9 Happens with other processes as well, not just ps. The machine is a Quad-CPU, 1Gig RAM, hardware raid (striped and mirrored) in case it makes a difference. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: not really reproducable as such, it just happens. Additional info: machine was upgraded from RH6.2 to 7.1. 6.2 did not have this problem. It's also running Clearcase 4.1 and has the mvfs kernel module loaded.
Can you tell me what the mvfs kernel module is ? Since something weird is happening any kernel module might be involved....
the mvfs module is a filesystem that ClearCase uses. According to Rational, redhat and clearcase should work together.
This "kernel bug" message means something is doing something wrong with the inode (filesystem metadata) administration, and usually when that happens, a filesystem is doing something wrong. Could you please ALSO report this to Rational as it is likely a problem in their module.
This kernel oops is the result of a defect in the mvfs module. This is fixed by the following patches to ClearCase: clearcase_p4.2-10 clearcase_p4.1-23.
Systems with binary only modules aren't supported anyway