Steffen Weiberle wrote:
> Thanks. Without looking at the RFE,
>> Since the comments aren't public I pasted the relevant stuff here:
>> They're primariliy necessary due to (among other things) the fact
>> that an NFS operation may translate to an over-the-wire call, and
>> in fact may open a TCP/UDP connection to the server (if the mount
>> has been inactive for long enough, or there is a failover, or a
>> number of other reasons).
>> While the semantics of process P in zone A doing a read(2) that
>> causes zone B to do network activity on its behalf merely seemed
>> odd (recall that zones have distinct network identities), the
>> scenario of zone A performing a mount, and subsequently zone B
>> opening a new connection to the server such that the client appears
>> to have "migrated" from zone A to zone B seemed downright wrong.
> I don't follow the A to B argument. Zone A (the global zone, or the
> kernel which may be best identified by the global zone) is always making
> the requests, and hiding that it is B, or C, or D... who may be
> consuming or creating the data.
Just to clarify, these comments were made on the bug report several
years ago by the engineer working on this at the time. They are
no longer at Sun and nobody from the zone's team has had a chance
to revisit this yet.
zones-discuss mailing list