Comment 91 for bug 211631

OK ... doing a little more investigation it gets interesting to see what crazy things gnome does (you can also try clearing the dmesg log and then doing "echo 7 > /proc/fs/cifs/cifsFYI" before you logoff/umount and see what cifs operations are in dmesg)

What I see is that the slow operations are repeated calls (presumably by gnome) to querypathinfo (stat) on ".Trash-1000" ... see below
 fs/cifs/inode.c: Getting info on //localhost/stevef/.Trash-1000
 fs/cifs/cifssmb.c: In QPathInfo (Unix) the path //localhost/stevef/.Trash-1000

cifs has no way of knowing that this is useless and that we should ignore gnome's request

In addition, running with umount.cifs (/sbin/umount.cifs is not needed in most cases unless you are doing user mounts/umount) you get a call to "statfs" (umount.cifs has to verify that this is a cifs mount and AFAIK there is no cheap way to do this in Ubuntu - and so we are stuck calling statfs to check the fs "type" field to make sure that we are in fact unmount a cifs file system - but statfs also unfortunately returns other information that requires sending a request over the network ... it would be very helpful if there were a way to query ... just ... the file system's type and not the other dynamic information that requires going to the server). If you move umount.cifs out of sbin that should help, but the big problem seems to be the desktop querying for things it doesn't need to be doing during umount