On 12/19/2012 02:08 PM, Myklebust, Trond wrote: > On Wed, 2012-12-19 at 20:47 +0000, Orion Poplawski wrote: >> >> However, we need someway to be able to drop mounts after the network connection >> has been removed. This behavior is causing sever problems for our laptop and >> vpn users. >> >> Tested with: >> >> 3.6.11-3.fc18 >> nfs-utils-1.2.7-2.fc18 >> >> I've also filed https://bugzilla.redhat.com/show_bug.cgi?id=888942 > > No. What you need is a way to unmount _before_ you kill the network. > Once the network is gone, you are in severe data loss territory, and you > are entirely on your own dealing with that problem... > > Maybe one day we will get round to supporting offline mounts, but that's > not the case today. > I agree (see https://bugzilla.gnome.org/show_bug.cgi?id=387832 for example), however it happens (and, because of lack of support as indicated by the bug, hard to prevent) and it seems unfortunate to then subject the user to hanging mounts (which will effectively lock up the desktop). It currently is possible for sec=sys mounts, so I thought it would be worth while making it work for sec=krb5 mounts. The same data loss issues are present for both. We have put work in the past into making umount work for offline nfs mounts (https://bugzilla.redhat.com/show_bug.cgi?id=820707). In fact that looks remarkably familiar :). [ 131.832005] umount.nfs4 D f1585bc8 0 1959 1958 0x00000080 [ 131.832005] f1585c34 00000086 0000ea8a f1585bc8 c045a297 f705f110 644b6440 0000001c [ 131.832005] f1585bd8 c0cd5080 c0cd5080 00000282 f1585c00 f7591080 f3a27110 f1585c24 [ 131.832005] 00000000 c0d2e280 00000282 00000246 f1585c00 c097a273 f1585c2c f7ee11c5 [ 131.832005] Call Trace: [ 131.832005] [<c045a297>] ? __internal_add_timer+0x77/0xc0 [ 131.832005] [<c097a273>] ? _raw_spin_unlock_bh+0x13/0x20 [ 131.832005] [<f7ee11c5>] ? rpc_wake_up_first+0x65/0x180 [sunrpc] [ 131.832005] [<f7eda240>] ? rpc_show_tasks+0x1b0/0x1b0 [sunrpc] [ 131.832005] [<c09794d3>] schedule+0x23/0x60 [ 131.832005] [<f7ee064d>] rpc_wait_bit_killable+0x2d/0x70 [sunrpc] [ 131.832005] [<c0977fc1>] __wait_on_bit+0x51/0x70 [ 131.832005] [<f7ee0620>] ? __rpc_wait_for_completion_task+0x30/0x30 [sunrpc] [ 131.832005] [<f7ee0620>] ? __rpc_wait_for_completion_task+0x30/0x30 [sunrpc] [ 131.832005] [<c0978041>] out_of_line_wait_on_bit+0x61/0x70 [ 131.832005] [<c046c100>] ? autoremove_wake_function+0x50/0x50 [ 131.832005] [<f7ee198f>] __rpc_execute+0x11f/0x340 [sunrpc] [ 131.832005] [<c0507774>] ? mempool_alloc+0x44/0x120 [ 131.832005] [<f7ed8a50>] ? call_connect+0x90/0x90 [sunrpc] [ 131.832005] [<f7ed8a50>] ? call_connect+0x90/0x90 [sunrpc] [ 131.832005] [<c046c0a3>] ? wake_up_bit+0x23/0x30 [ 131.832005] [<f7ee1ec8>] rpc_execute+0x48/0x80 [sunrpc] [ 131.832005] [<f7ed9929>] rpc_run_task+0x59/0x70 [sunrpc] [ 131.832005] [<f7ed9a3c>] rpc_call_sync+0x3c/0x60 [sunrpc] [ 131.832005] [<f8a402fc>] _nfs4_call_sync+0x3c/0x50 [nfsv4] [ 131.832005] [<f8a403d5>] _nfs4_proc_getattr+0x95/0xa0 [nfsv4] [ 131.832005] [<f8a41bab>] nfs4_proc_getattr+0x3b/0x60 [nfsv4] [ 131.832005] [<f897f891>] __nfs_revalidate_inode+0x81/0x210 [nfs] [ 131.832005] [<f897fbd2>] nfs_revalidate_inode+0x62/0x90 [nfs] [ 131.832005] [<f89793ef>] nfs_check_verifier+0x4f/0x80 [nfs] [ 131.832005] [<f897b4da>] nfs_lookup_revalidate+0x2ba/0x440 [nfs] [ 131.832005] [<c055f8cb>] ? follow_managed+0x19b/0x200 [ 131.832005] [<c0560000>] ? unlazy_walk+0xf0/0x1a0 [ 131.832005] [<f897c184>] nfs4_lookup_revalidate+0x34/0xe0 [nfs] [ 131.832005] [<c055fedc>] complete_walk+0x8c/0xc0 [ 131.832005] [<c05611b3>] path_lookupat+0x63/0x650 [ 131.832005] [<c05617ca>] do_path_lookup+0x2a/0xb0 [ 131.832005] [<c0563df6>] user_path_at_empty+0x46/0x80 [ 131.832005] [<c097d440>] ? vmalloc_fault+0x176/0x176 [ 131.832005] [<c097d5f7>] ? do_page_fault+0x1b7/0x450 [ 131.832005] [<c0563e4f>] user_path_at+0x1f/0x30 [ 131.832005] [<c05707b1>] sys_umount+0x41/0x340 [ 131.832005] [<c04bd59c>] ? __audit_syscall_entry+0xbc/0x290 [ 131.832005] [<c04bdac6>] ? __audit_syscall_exit+0x356/0x3b0 [ 131.832005] [<c0980fdf>] sysenter_do_call+0x12/0x28 I wonder if it never did get fixed for krb5 mounts then... Bah. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion@xxxxxxxx Boulder, CO 80301 http://www.nwra.com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
