NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

kern/42616: tmpfs crashes on unmount after testing with "fsstress"

>Number:         42616
>Category:       kern
>Synopsis:       tmpfs crashes on unmount after testing with "fsstress"
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Jan 13 22:20:00 +0000 2010
>Originator:     Greg A. Woods
>Release:        netbsd-4 2009/07/09
Planix, Inc.; Toronto, Ontario; Canada
Architecture: i386
Machine: i386 (Intel Pentium 4 with HTT enabled)

        After reading about FreeBSD importing tmpfs, and then getting
        it to work reliably with the "fsstress" program, originally from
        SGI, but also ported to DragonFly, I thought I'd try it on
        NetBSD-4 to see if I should switch my production systems over to
        using tmpfs yet or not.

        tmpfs is definitely faster than mfs, and puts lots less load on
        the system, but it still seems to be broken in netbsd-4, at
        least on MP systems.


        run several iterations of fsstress (compiled with -DNO_XFS),
        such as with:

                mkdir /tmpfs
                mount -t tmpfs -o -s512m,nodev,nosuid tmpfs /tmpfs
                cd /tmpfs
                cp ~/work/fsstress/fsstress .
                for r in 0 1 2 3 4 5 6 7 8 9; do
                        ./fsstress -n 1000 -p 4 -d test
                        rm -rf test
                cd /
                umount /tmpfs

        in at least one test rm(1) complained something like this after
        the first three or four runs (from memory):

                rm: fts_read No such file or directory

        ls(1) shows the "test" directory does still exist, but rm(1)
        can't remove it.

        The following panic occurs during the unmount operation:

        panic: pool_destroy: pool busy: still out: 135
        Stopped in pid 1489.1 (umount) at       netbsd:cpu_Debugger+0x4:        
popl    %ebp
        db{1}> trace
        cpu_Debugger(c09807a2,d8c05af8,d8c05aec,202,c0a09d14) at 
        panic(c09b4160,87,34c,c04551a8,c40cb1c8) at netbsd:panic+0x155
        tprintf_open(c40cb28c,0,d8c05b6c,c0316032,c40cb28c) at 
        tmpfs_str_pool_destroy(c40cb28c,d90b92f4,0,c048c00e,c0aa1fc0) at 
        tmpfs_unmount(c40ca000,0,d8b9c4bc,d8b9c4bc,24a) at 
        dounmount(c40ca000,0,d8b9c4bc,c09b65bc,213) at netbsd:dounmount+0x108
        sys_unmount(d8b9c4bc,d8c05c48,d8c05c68,80717c4,8071000) at 
        syscall_plain() at netbsd:syscall_plain+0x1a8
        --- syscall (number 22) ---
        db{1}> reboot


        unknown -- problem may not even be directly in tmpfs.

        If this is already fixed in netbsd-5 is there any chance of
        getting the fix back-ported to netbsd-4?

        (and if not, and if the bug is in tmpfs, perhaps the fix is
        available in changes made to tmpfs for FreeBSD?)

Home | Main Index | Thread Index | Old Index