[Gluster-devel] Change in glusterfs[master]: Do not hardcode umount(8) path, Do not umount too early.

[Emmanuel Dreyfus]

I switch back to gluster-devel@ which seems a better place for
discussing this.

Csaba Henk (Code Review) <review at dev.gluster.org> wrote:

> From the service's point of view it's fatally wrong to make assumptions
> on the clients use cases. We provide the lazy option not because we
> speculated of its usefulness and ended up with a positive evaluation, but
> because it's part of the system interface we ventured to export and we
> want to do a good job at that.
> 
> If we are on a system that does not support lazy umount,  the correct
> behaviour is to fail lazy requests with errno ENOSYS.

What about spawning a thread that will periodicaly attempt to unmount?
If there is still activity, it will get EBUSY, and once everything is
over, it wil succeed.

A previous patchset had a general umount_lazy() wrapper that used either
lazy unmount if available, or a periodcal unmount thread otherwise. I
removed it because I was suggested lazy unmount was not that important,
but if it is, then I beleive it is a fair solution to this portability
problem.

For the specific replace-brick case: Are lazy unmount really required
here? If we try to unmount at the time the mount point is removed by
rmdir(), there is no more pending activity and umount succeeds without
lazy unmount. That is the "Do no umount too early" part of my patchset.

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu at netbsd.org