unmount issues with 2.4.5-ac5, 3ware, and ReiserFS (was: kernel-2.4.5 bug)

Here are some experiences with the unmount issue(s) concerning Linux kernel 2.4.5-ac5, (in my case) the 3ware RAID controller, and ReiserFS.

I'm using kernel 2.4.5-ac5 and have a 3ware Escalade 6400 controller (firmware upgraded to v6.6 to fix RAID5 issue) with four disks on 64k RAID5.

I do not get kernel oopses when I unmount, but I noticed that unmounts (whether called by root or during shutdown) "freeze" and cause the controller to do an initializing scan of the array to verify parity (which it normally only does when the first laying out of zeroes doesn't go properly).

After a first unmount (when called by root), subsequent unmount attempts or even syncs (using the sync utility) will "freeze" as if waiting for the drives to respond. Other file activity is normal but a little slow (as they normally are when initializing scans are being done by the hardware RAID controller).

I haven't found any NULLs at the start of recently created or modified files, and things seem to be okay except for this issue when unmounting. As a matter of fact during the last time this "freeze" happened I gathered my wits to help me from panicking (the company's data's on this box, it's our main Samba fileserver) and created a small file with a few text, then stopped all my applications (the ones I could stop using the /etc/init.d scripts) and killed the power.

When I rebooted, the 3ware controller's BIOS of course told me that the initializing scan would commence after the OS was loaded (as expected). Boot up was normal, ReiserFS replayed transactions pretty quickly without any wierd comments, and then I checked the files I remember were changed or the small test file I created and ... everything seemed to be in order, intact, and as if nothing untoward happened. Well, at least I didn't find anything that looked untoward/messed up. I hope everything is indeed in order (I've got both my fingers crossed and this honestly makes typing a little difficult ;> ).

I'm staying on 2.4.5-ac5 for whatever it's worth (putting my life on the line for the community? kidding...) and will report anything new. I will be on the lookout for later ac patches, 2.4.6 ... and hopefully anything anybody can share with me about this. I hope we'll see an end to these issues soon. May all those actually doing work on it be blessed. :)

--> Jijo

--
Linux, MS-DOS, and Windows NT ...
... also known as the Good, the Bad, and the Ugly

Can you tell me if 2.4.5-ac4 is ok. ac5 has a small 'obviously correct' reiserfs module unload change that seems the first suspect

I have seen this same problem with unmounting in 2.4.5-ac5, it was perfectly fine in 2.4.5-ac3 and ac4. I would guess the module unload is what did it.

Jordan

2.4.5-ac4 was fine, 2.4.5-ac5:

/space in /etc/fstab:

/dev/hda10 /space1 reiserfs defaults 1 2

strace umount /space1:

open("/usr/lib/locale/en_US/LC_TIME", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=2441, ...}) = 0 old_mmap(NULL, 2441, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4001f000
close(3) = 0
open("/usr/lib/locale/en_US/LC_NUMERIC", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=44, ...}) = 0 old_mmap(NULL, 44, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40020000
close(3) = 0
open("/usr/lib/locale/en_US/LC_CTYPE", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=104804, ...}) = 0 old_mmap(NULL, 104804, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40137000
close(3) = 0
SYS_199(0x40131ad8, 0, 0x40132760, 0x40130210, 0) = 0

semop(1074993880, 0x40130210, 0)        = 0
brk(0x8056000)                          = 0x8056000
readlink("/space1", 0xbfffe51c, 4095)   = -1 EINVAL (Invalid argument)
open("/etc/mtab", O_RDONLY)             = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=680, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40021000
read(3, "/dev/hde1 / ext2 rw 0 0\nproc /pr"..., 4096) = 680
read(3, "", 4096)                       = 0
close(3)                                = 0
munmap(0x40021000, 4096)                = 0

oldumount("/space1"

and there it hangs. The kernel doesn't hang, but while 'mount' displays /space1 as mounted, ls /space1/ says nothing. df -m reveals:

Filesystem 1M-blocks Used Available Use% Mounted on
/dev/hda10 2015 907 1005 48% /space1

Good luck,
Jurriaan

The music in my heart I bore long after it was heard no more.
        William Wordsworth
GNU/Linux 2.4.5-ac5 SMP/ReiserFS 2x1402 bogomips load av: 5.60 2.71 1.16

/dev/sdb1 /var/log/LOGS reiserfs defaults 0 0

strace /sbin/umount /dev/sdb1

execve("/sbin/umount", ["/sbin/umount", "/dev/sdb1"], [/* 30 vars */]) = 0
brk(0) = 0x80500c0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40016000

open("/etc/ld.so.preload", O_RDONLY)    = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(0x3, 0xbfffedb4)                = 0

old_mmap(NULL, 37548, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40017000
close(3) = 0
open("/lib/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\264\323"..., 1024) = 1024
fstat64(0x3, 0xbfffedfc) = 0
old_mmap(NULL, 1116516, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40021000 mprotect(0x40128000, 39268, PROT_NONE) = 0

old_mmap(0x40128000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x106000) = 0x40128000
old_mmap(0x4012e000, 14692, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4012e000
close(3)                                = 0
munmap(0x40017000, 37548)               = 0
getpid()                                = 421
brk(0)                                  = 0x80500c0
brk(0x80500e8)                          = 0x80500e8
brk(0x8051000)                          = 0x8051000
SYS_199(0x4012ca58, 0, 0x4012d760, 0x4012b1f0, 0) = 0
semop(1074973272, 0x4012b1f0, 0)        = 0
brk(0x8053000)                          = 0x8053000
readlink("/dev", 0xbfffe96c, 4095)      = -1 EINVAL (Invalid argument)

readlink("/dev/sdb1", 0xbfffe96c, 4095) = -1 EINVAL (Invalid argument)
open("/etc/mtab", O_RDONLY|0x8000) = 3
fstat64(0x3, 0xbffff6ec) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000 read(3, "/dev/sda6 / ext2 rw 0 0\n/dev/sda"..., 4096) = 273

read(3, "", 4096)                       = 0
close(3)                                = 0
munmap(0x40017000, 4096)                = 0

oldumount("/var/log/LOGS"

Ditto.

In my case:

- before umount:

root@logs2:/mnt# df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/sda6              8130996   1356716   6354584  18% /
/dev/sda7              8130996        20   7711280   1% /spare
/dev/sda8              2038472        44   1933204   1% /home
/dev/sda9              2038472     41964   1891284   3% /tmp
/dev/sda10            14016248     46444  13969804   1% /mnt
/dev/sdb1             35542688     32840  35509848   1% /mnt/log/LOGS

- after (unfinished od course) umount:

lech7@logs2:~$ df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/sda6              8130996   1356572   6354728  18% /
/dev/sda7              8130996        20   7711280   1% /spare
/dev/sda8              2038472        44   1933204   1% /home
/dev/sda9              2038472     41968   1891280   3% /tmp
/dev/sda10            14016248     46540  13969708   1% /var
/dev/sdb1             14016248     46540  13969708   1% /var/log/LOGS

	Leszek.

-- [email protected] 2:480/33.7          -- REAL programmers use INTEGERS --
-- speaking just for myself...

Looks like -ac6 has fixed this problem :)

	Leszek.

-- [email protected] 2:480/33.7          -- REAL programmers use INTEGERS --
-- speaking just for myself...

known VFS bug, ask viro for details, 2.4.5 is not stable because of it, use 2.4.4

Hans

Or 2.4.5-ac6

Different issue. Missing lock_kernel()/unlock_kernel() in kill_super() appeared in -pre6 and was fixed in -ac2 or so. -ac5 apparently had introduced something new, that had been reverted (fixing the problem) in -ac6.

thanks for clarification.

Hans