Matthew Dillon schrieb:
> :commit 5ba58ea0cdaa8790454100de6bc7ac03941501d9
> :Author: Michael Neumann <mneumann@ntecs.de>
> :Date: Tue Nov 24 20:42:36 2009 +0100
> :
> : hammer expand: Fix "umount flushing...giving up!" problem.
> :
> : No need to modify header of the volume to be added. This fixes
> : the outstanding "umount flushing...giving up" problem.
>
> I had totally forgotten you had asked me to look at that.
> Sorry about that.
No problem! I know you must be super busy all the time :)
I am still confused *why* this commit fixes the problem. I thought maybe
the flusher threads do not know about the new volume (due to caching a
struct or so), looked through the code but couldn't find evidence for
that. If I modify a header field of the new volume, the flusher
thread is "hanging" on the hmp->volu_list queue (this gives the "umount
flushing..." output), so maybe there a bug somewhere else?
Other than that, I am not sure if I did all the locking right. It seems
that there is no locking on hmp->nvolumes at all, so at least
theoretically this could lead to a race somewhere.
Regards,
Michael