Bug 3096 - umount fails if cable is unplugged even with -f or -l options
umount fails if cable is unplugged even with -f or -l options
Product: CifsVFS
Classification: Unclassified
Component: kernel fs
All Linux
: P3 normal
: ---
Assigned To: Steve French
Depends on:
  Show dependency treegraph
Reported: 2005-09-14 05:20 UTC by Eric Valette
Modified: 2006-05-06 11:42 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Eric Valette 2005-09-14 05:20:52 UTC
Similar problem/solution has already been resolved/proposed with NFS. The
problem is that with laptop plug/unplug, even with ifplug tools you cannot do
anything as umount hangs
Comment 1 Steve French 2005-09-14 09:41:22 UTC
What is the Kernel version and cifs version? (see the top of
/proc/fs/cifs/DebugData or for older cifs modules "/sbin/modinfo
Comment 2 Eric Valette 2005-09-14 13:29:20 UTC
Kernel stock. CIFS version 1.35.

What I would like to be able to do is to plug unplug a running linux system and
have everything smothly running. Without doing ifup/ifdown on eth0, due to cache
of hw address, connection does not immediately come up. ifplugd can manage that
automatically but the umount/mount still needs to be done in order to either
shutdown properly an unplugged machine (after cable deconnexion) or to get
access to CIFS share after a plug/unplug.
Comment 3 Steve French 2005-11-04 10:39:46 UTC
I plan on implementing umount --force in cifs, but it would be very helpful if I
knew which location you were blocked in when umount fails.

There is a type of request (byte range locks and more rarely directory change
notify request) which can block, and there is a bug in Windows XP which used to
cause a lock response to appear corrupt and thus hang a request incorrectly
(thus potentially blocking umount), but I need to understand if your case is
different from that one.

What would be helpful is the dmesg output (which includes stack traces of
blocked process) after issuing "echo t > /proc/sysrq-trigger") just before the
umount so I could see where in cifs (if at all) any requests are blocked.
Comment 4 Steve French 2006-05-06 11:42:14 UTC
umount -f works in cifs code from roughly 1.37 on (perhaps a bit earlier).  So kernels 2.6.16 certainly should be fine (probably earlier too).  Also the timeout processing is much better - after unplugging the cable few types of requests block more than 20 to 30 seconds before returning an error.