Hello, I'm doing another series of patches regarding project unionmount and I'll start with explaining why I do this while the first series of patches has not been completely approved.
antrik suggested that I should implement the unionmount functionality *first*, and only then focus on trimming the other parts of unionfs to the needs of unionmount. The idea is to do as few modifications to unionfs as it should be necessary to make unionfs capable of hosting this piece of new functionality. It was concluded that it is best to add a command line option: ``--mount=MOUNTEE'', whose value should be the path to the mountee. This will result in fewer modifications to command line handling but, OTOH, will collect sufficient information for unionmount. This said, I state that the PREVIOUS SERIES OF PATCHES IS WRONG and should not be paid attention henceforth. As it has been said above, this series of patches introduces option ``--mount'', used to specify the path to the mountee. To mount a translator in unionmount mode, one should do (presently): # settrans -a <node> unionfs -u --mount=<translator> It is probable that in the future more changes to command line handling policy will be committed, modifying the syntax accordingly. 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). I tried to follow the pieces of advice I have been offered WRT my previous patch series and I hope I have improved a bit... :-) Regards, scolobb
