DragonFly BSD
DragonFly commits List (threaded) for 2009-11
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: git: hammer expand: Fix "umount flushing...giving up!" problem.


To: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
From: Michael Neumann <mneumann@xxxxxxxx>
Date: Thu, 26 Nov 2009 11:16:01 +0100

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



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]