Bug 3848
Summary: | smbfs not does not survive a S3 suspend/resume cycle | ||
---|---|---|---|
Product: | File System | Reporter: | kusi (birrenweggen) |
Component: | Samba/SMB | Assignee: | Luming Yu (luming.yu) |
Status: | REJECTED INSUFFICIENT_DATA | ||
Severity: | normal | CC: | acpi-bugzilla, bunk, diegocg |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.9 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: | dmesg |
Description
kusi
2004-11-30 14:54:40 UTC
Created attachment 4180 [details]
dmesg
This bug is still present in 2.6.11 using Gentoo. This bug is basically a showstopper for using a laptop (->suspend) in a local network (->samba). Is this the wrong place to report this bug, does this belong to samba.org? I'm not sure but I don't think any network filesystem can survive from a suspend/resume cycle (suspend will break network connection). To me, a user script should unmount all network filesystems before suspend and remount it after resume. I am not sure about that, I think Windows for example survives a suspend/resume cycle. But what is definatively a bug is the fact that if you do not umount a samba share, you'll enter a error state upon resume which is not repairable. You neither can umouunt nor mount, (even with --force), reload modules, etc... It's not just loosing the connection but the necessity to reboot what I'm talking about here. But I think I found an acceptable workaround: It seems to be sufficient to lazy unmount (umount -l /sambashare/) before resume and remount the share after resume. The application does not crash and is fully functional after resuming. In my opinion, the lazy unmount should be integrated in the suspend hook of smbfs (if there is any). Still better than reboot... this problem is still present with 2.6.15-rc2-git2 and associated grekh-all. in contrast, nfs survives suspend/resume very nicely. actually, if i copy some large file and suspend during the processs, copying is finished after resuming. smbfs mounts are completely unaccessible and produces similar timeouts for me. SMBFS is being deprecated, you should be using CIFS instead (see http://lwn.net/Articles/183693/) IMO this bug should be closed - please try CIFS instead, and if you find some problem with cifs please report it Please close this bug if the problem doesn't appear in recent kernels (2.6.18 and later). |