A couple clarifications:
1) We really want the network file systems to be unmounted (or at least synced) 
before the network goes away.  You do not want to risk losing file system data 
which has been cached by the Linux memory management layer.

2) If there is cached write data, we do want the file system to try as
hard as reasonably possible (perhaps forever in the case of mounting
with the "hard" mount option rather than the default "soft" mount)
before giving up - the network which is down for a few seconds, may
recover in most cases (where exactly we are in shutdown of the system
may be hard to detect in this path in the kernel)

3) CIFS already does do the obvious - it does not attempt to send network 
requests in umount (SMB "tree disconnect" followed by SMB "ulogoff") if the 
session is already dead (the server implicitly closes "tids" and "smb uids" 
when the socket crashes).   Write requests just prior to the umount getting to 
the kernel would cause attempts at reconnect, but simply from the kernel cifs 
driver perspective umounting should not cause network traffic if the session is 
already dead
e.g. see this code excerpt from CIFSSMBTDis
        /*
         * No need to return error on this operation if tid invalidated and
         * closed on server already e.g. due to tcp session crashing. Also,
         * the tcon is no longer on the list, so no need to take lock before
         * checking this.
         */
        if (tcon->need_reconnect)
                return 0; 

and similarly in CIFSSMBLogoff:
        if (ses->need_reconnect)
                goto session_already_dead; /* no need to send SMBlogoff if uid
                                              already closed due to reconnect */

-- 
CIFS/SMBFS shares not unmounted before network is shut down
https://bugs.launchpad.net/bugs/211631
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to