bug-hurd
[Top][All Lists]
Advanced

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

Re: [PATCH 0/3] Implement unionmount on top of unionfs


From: Sergiu Ivanov
Subject: Re: [PATCH 0/3] Implement unionmount on top of unionfs
Date: Mon, 29 Jun 2009 21:53:59 +0300
User-agent: Mutt/1.5.18 (2008-05-17)

Hello,

On Mon, Jun 29, 2009 at 01:35:39AM +0200, olafBuddenhagen@gmx.net wrote:
> On Thu, Jun 11, 2009 at 08:59:18PM +0300, Sergiu Ivanov wrote:
> > This implementation of unionmount implements lazy translator startup,
> > because it is impossible to start the mountee during the
> > initialization of unionfs. The reason is that most translators (at
> > least) try to stat their underlying node, i.e. invoke an RPC on it. If
> > the mountee is started during unionfs initialization phase, it invokes
> > an RPC on the proxy node provided by unionfs, but unionfs cannot
> > process it appropriately, because it has not yet finished initializing
> > itself (deadlock).
> 
> So it's absolutely impossible to start the mountee before the translator
> startup is finished? That would be unfortunate, as we can't pass back
> error codes to settrans that way...

I'm thinking of messing in with netfs_server_loop() and inserting the
mountee startup code after a call to
ports_manage_port_operations_multithread(), but I'm not sure whether
this is appropriate.  For example, I could invoke it with a shorter
timeout *before* netfs_server_loop() to force servicing some possible
RPCs coming from the mountee to enable it to start.

Regards,
scolobb




reply via email to

[Prev in Thread] Current Thread [Next in Thread]