Hello, On Mon, Jun 29, 2009 at 01:35:39AM +0200, olafbuddenha...@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
