Re: Unionmount. Basic details

[Sergiu Ivanov]

Hello,

Da Zheng <zhengda1936@gmail.com> writes:
> Carl Fredrik Hammar wrote:
>>> It is not fully clear right now -- I realized that there is another
>>> decision to make: should the unionmount translator be directly visible
>>> as the translator attached to the mount node; or should it serve as a
>>> proxy, forwarding all requests on the filesystem port to the target
>>> translator -- thus making itself more or less transparent, so it appears
>>> as if the target was attached to the mount node directly?
>>>
>>> I tend towards the latter.
>>>     
>>
>> I think the latter makes a lot more sense.  I can't think of any reason
>> to let the mountee be aware that it's detached from the underlying
>> file system.  If anything it would just confuse it.
>>   
> I think the first approach has its advantage. One very important
> reason is the performance. We are writing OS, after all.
> With the second approach, all requests from the application to the
> file system are twice expensive as before.
> But with the first approach it is possible that unionmount translator
> can expose the port to the node in the underlying file system to the
> outside world and later the application can access the underlying node
> with that port directly (unionmount isn't involved in the following
> operations such as reading and writing).

It seems to me that the two suggested approaches are not about keeping
unionmount in between the client and the underlying filesystem or
not. Consider the following situation: you send an fsys_syncfs RPC to
unionmount: the question is whether unionmount should forward this RPC
to the mountee or not. From this point of view, the first approach says
that unionmount is visible as a separate translator, while the second
approach suggests that unionmount be as transparent as possible, so that
the client should in most cases have the illusion of its absence.

Returning to what you say about ports, I fully agree with your
opinion. Lookups under nsmux mirror tree end up in ports to proxy nodes,
but this is because nsmux needs to control the requests coming from the
client. I cannot see why unionmount should need such control, so I am
completely for having it yield ports to the underlying filesystem(s)
directly.

> I might be mistaken. I don't know much how unionfs works and whether
> unionmount can work in this way.

To my understanding, unionfs gives off to the client ports to the
underlying filesystem(s), thus getting out of the way of all RPC not
connected with lookup.

Regards,
scolobb