Re: 9P2000.s vs 9P2020 vs. ? (Was Re: [9front] Slow cp, support for 9P2000.s)

[hiro <23hiro@gmail.com>]

none of the solutions so far proposed properly extend the original
abstraction without *creating* new holes.

i don't think there's "a big hole" without our optimization attempts...
as an example, when we have streams via the network, we will fill
buffers and packets have to be dropped.

if everything is local ressource usage fairness is only provided by
our scheduling, if everything is remote, let's say using multiple
hops, this creates new distributed scheduling problems and a lot of
distributed unfairness.

right now we don't notice, but this is the real hole here, elegantly
avoided so far by making everything synchronous.

On 5/18/20, ori@eigenstate.org <ori@eigenstate.org> wrote:
>> Since there's no existing discussion I can see, and IRC isn't meant for
>> searching for answers to questions, is there anyone willing to summarize
>> the state of solving problems like streaming for 9P?
>
> Nothing that we're satisfied with at the moment, though there's
> thoughts on providing early acks on writes, and io agents to do
> bring at least some of the io logic closer to the data, instead
> of shouting across the internet for every transaction.
>
>> If Aiju remembers correctly, there were two things where 9P2000.s was
>> found wanting:
>> 1) it breaks the syscall interface; and
>> 2) it forces 9P to run over TCP.
>>
>> FWIW, I finally finished reading through all of John's thesis,
>> rather than just skimming, and I think John did a nice review of
>> the previous work done in this area and presenting why he chose
>> the solution he did.  His solution used TCP, but from his
>> write-up, I don't see a technical reason why another transport
>> protocol[1] could not be used.  That would leave only breaking
>> the syscall interface.
>>
>> Does breaking the syscall interface mean that it's merely adding a
>> syscall? Or does it mean something else?
>
> Yes -- any program that would want to take advantage of it needs
> to be touched.  And would need heuristics: a 9p roundtrip is
> still fewer roundtrips than a TCP handshake, so using it blindly
> would slow things down when handling small files.  We also, by
> design, make no distinction between remote and local files, so
> there would need to be more guesswork here.
>
> It also doesn't help with, for example, walking a directory
> heirarchy, so things like browsing a mail archive over 9p will
> remain painfully slow.
>
> Finally, if we want an ad-hoc solution like this, we can do it
> entirely in userspace, with a TCP server sitting on a remote
> server, and a local 9p server that opens a TCP connection to
> that server and streams the whole file, providing it locally.
> I don't think this would be very hard to write, and would
> probably give the benefits of streams, without needing any
> changes to the existing code. (Thinking about this, it may
> actually be worth writing.)
>
> So. in short: This is a big hole in the abstractions provided
> by 9p, and it doesn't solve the problem completely.
>
>> Right now hget(1) is an rc script that uses webfs(4).  So if
>> I'm at a terminal far away and am using webfs provided by the
>> server I'm connected to, hget would be slow for a large file
>> because the file would be transferred over 9P. It's no better
>> than Plan 9's implementation, but no worse either.
>>
>> [1] https://en.wikipedia.org/wiki/Category:Transport_layer_protocols
>
>