Em Tue, 29 Jan 2008 11:48:29 -0500 Erez Zadok <[EMAIL PROTECTED]> escreveu:
| In message <[EMAIL PROTECTED]>, Dave Miller writes: | > Luiz Fernando N. Capitulino wrote on 1/29/08 10:05 AM: | > | > > https://bugzilla.filesystems.org/show_bug.cgi?id=604 | > > | > > Something I've realized now is that it seems the bug depends on the | > > right timing to be triggered. I've put those commands to reproduce it | > > in a script and I can't reproduce that bug, but I get a different OOPS | > > when rebooting... | > | > I've been experiencing the reboot issue myself... what appears to | > happen is that the initscript for the nfs client tries to unmount all of | > the NFS mounts during shutdown, however, since the NFS mount is a branch | > of a unionfs, unionfs gets confused when it disappears. If I unmount | > the unionfs mount first before rebooting then there's no OOPS. | > In thinking about it, I'm not really sure what a good way to fix it | > would be. unionfs could mark something on the NFS partition as "in use" | > so it won't unmount (and it might do that already) but that would only | > confuse things during shutdown. I was sort of planning on writing up an | > initscript to umount any unionfs partitions and getting that in position | > to run prior to the equivalent NFS one during shutdown. | | Unionfs holds a vfsmount reference on every lower branch, which is released | when unionfs is unmounted; this is needed for normal operations, so the | lower branches don't disappear unexpectedly. Therefore, it should be | impossible for one to unmount a lower branch directly -- you should get an | EBUSY. So I'm curious what happens during shutdown that causes the lower | branch (nfs or any) to be unmounted? Does your shutdown code try to force | the unmount ("umount -f" or "umount -l")? If so, I'll have to figure out a | way to detect when the "rug has been pulled from underneath me" and deal | with it somehow. | | Also, does anyone know if there's a way to make linux reorder the entries in | /proc/mounts so stackable file systems show up first? That way most | shutdown scripts will try to unmount the upper layers first. | | If there is no such way, then we may have to resort to our own /etc/init.d | shutdown script that understands stackable file systems. In that case, if | you or anyone develops such a script, I don't mind distributing it on the | Web site. Yeah, maybe.. But we have to fix that OOPS too. I've captured the backtrace, but I'm not sure what the shutdown script is doing when the OOPS happens. I'm still investigating. Should I open a ticket for that one too? The first and last lines of the backtrace are mixed with the output of the Mandriva's shutdown script because I was running it with 'bash -x' when I got the OOPS. """ BUG: Dentry dc1ad6b8{i=6b5e2,n=} still in use (1) [unmount of nfs 0:15] me/ { print $1 }------------[ cut here ]------------ kernel BUG at fs/dcache.c:648! invalid opcode: 0000 [#1] Modules linked in: sit tunnel4 unionfs nfs af_packet ipv6 nfsd lockd nfs_acl auth_rpcgss sunrpe Pid: 4956, comm: umount Not tainted (2.6.24-1mdv #1) EIP: 0060:[<c017fcf3>] EFLAGS: 00010282 CPU: 0 EIP is at shrink_dcache_for_umount_subtree+0x150/0x204 EAX: 0000004b EBX: 00000001 ECX: c011e992 EDX: dfb58810 ESI: dc1ad6b8 EDI: dc1ad730 EBP: dd51be44 ESP: dd51be14 DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 Process umount (pid: 4956, ti=dd51a000 task=dfb58810 task.ti=dd51a000) Stack: c0360c1d dc1ad6b8 0006b5e2 dc1ad730 00000001 e0e24b5a dd5fce3c 0006b5e2 00000005 dd5fcc00 e0e22308 00000001 dd51be50 c0180734 dd5fcc00 dd51be68 c01729c1 00000000 c0172b40 00000015 e0e3728c dd51be74 c0172aa3 dd512060 Call Trace: [<c01054b2>] show_trace_log_lvl+0x1a/0x2f [<c0105562>] show_stack_log_lvl+0x9b/0xa3 [<c0105610>] show_registers+0xa6/0x178 [<c01057f8>] die+0x116/0x202 [<c02caaf3>] do_trap+0x89/0xa2 [<c0105ba3>] do_invalid_op+0x88/0x92 [<c02ca8ba>] error_code+0x6a/0x70 [<c0180734>] shrink_dcache_for_umount+0x2c/0x39 [<c01729c1>] generic_shutdown_super+0x18/0xce [<c0172aa3>] kill_anon_super+0xc/0x35 [<e0e07350>] nfs_kill_super+0xf/0x19 [nfs] [<c0172b45>] deactivate_super+0x5d/0x6f [<c0183ac0>] mntput_no_expire+0x44/0x6f [<e0d79ee6>] unionfs_d_iput+0x6d/0x130 [unionfs] [<c017fd56>] shrink_dcache_for_umount_subtree+0x1b3/0x204 [<c0180734>] shrink_dcache_for_umount+0x2c/0x39 [<c01729c1>] generic_shutdown_super+0x18/0xce [<c0172b45>] deactivate_super+0x5d/0x6f [<c0183ac0>] mntput_no_expire+0x44/0x6f [<c01770c2>] path_release_on_umount+0x15/0x18 [<c01841a1>] sys_umount+0x1c4/0x1ce [<c0103e02>] sysenter_past_esp+0x6b/0xc9 ======================= Code: 3c 02 00 00 89 44 24 18 8b 45 ec 89 4c 24 14 89 5c 24 10 89 7c 24 0c 89 74 24 04 89 44 2 EIP: [<c017fcf3>] shrink_dcache_for_umount_subtree+0x150/0x204 SS:ESP 0068:dd51be14 ' /proc/swaps +---[ end trace babd5835339779c5 ]--- """ -- Luiz Fernando N. Capitulino _______________________________________________ unionfs mailing list: http://unionfs.filesystems.org/ unionfs@mail.fsl.cs.sunysb.edu http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
