I switch back to gluster-devel@ which seems a better place for discussing this. Csaba Henk (Code Review) <review@xxxxxxxxxxxxxxx> 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@xxxxxxxxxx _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
