A product I am working on manages storage. We are currently porting it from Solaris to Linux.
The product allows its user, among other things, to add and remove file server volumes, where these volumes are exported using the NFS or the CIFS protocol.
The problem is that when the user requests to remove a volume, it is quite possible that the volume is busy, since there is a client that uses it. This is particularly a problem with CIFS volumes (exported using a Samba server).
We have considered using lazy umount, but how can I know when the umount completes and I can actually remove the volume?
Solaris has a "force" umount, which we use. It performs the umount despite any open files on the volume. Unfortunately, Linux does not support it. The "-f" flag does not work this way, and by the documentation (and my tests) only works on remote NFS volumes I mount locally.
If I could have shut Samba up, then there would be no problem, since a Samba process is the one that keeps this file system busy.
I have tried using smbcontrol to close down the specific share that is the one we want to remove. It didn't cause Samba to close the connection either.
I have considered killing the smbd process that handles the client that accesses this share, but the problem is that the same client may use another share at the same time. I feared that killing the process will impair other I/O operations done by the same client to the other shares.
Nonetheless, this is an alternative that is still under consideration if I will not be able to come out with a better solution.
---------- Post updated at 09:34 AM ---------- Previous update was at 08:36 AM ----------
I have retried smbcontrol, and it seems that if I give it the actual process number of the smbd process that opens the exported directory then it works.
Giving it the "smbd" as the process name does not work, as i specified earlier.
I am going to explore this method and I hope it solves my problem.
On Linux, lazy unmount denies further attempts to use the filesystem, but doesn't invalidate handles are open already, and keeps the filesystem technically mounted until the last one is closed. So if anything keeps holding that partition open, you've now got the worst of both worlds: A filesystem that can't be unmounted, can't be used, and can't be reinstated(because a lazy unmount can't be aborted). If something's persistently holding open the disk and you can't kill it, a lazy unmount will turn an annoyance into a disaster.
So this option is fairly dangerous.
You'll be able to tell when (or if!) it ever completes via df -h, I think.
If you have the necessary root permissions to unmount something, why can't you just stop samba properly?
As I have written earlier, the Samba server cannot be stopped since there may be a number of volumes that are exported, and it is undesirable to disturb I/O to/from the other volumes.
I agree that the lazy umount is not good in my case, since if I want to deallocate the resources used for the volume I unmounted, I have no idea when they will actually be free.
As I mentioned above, I am currently exploring the possibility to use "smbcontrol stop-share" to break the connection to the volume I want to umount, which should allow me to use normal umount after that.
I wonder if there is a better solution.
Latest news: I tested the smbcontrol solution integrated to our product and it works!