From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f48.google.com ([209.85.128.48]) by ewsd; Mon May 18 05:10:12 EDT 2020 Received: by mail-wm1-f48.google.com with SMTP id z4so7311856wmi.2 for <9front@9front.org>; Mon, 18 May 2020 02:10:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=xFQucDSeIky6RZJm1H0SPJFqxE8R+gB7potxyvQnxrg=; b=B5Bsnvejoj05L3IOefhKRkc+zgTIhq2+27WxT/Fh+A7Tspiu1Rc9akuzMcDV4hWJPa W5f10apMd84mz60lCu7YUYESTVFDqc4gxhCpMWaK2D439gx/Cu3cFVJ50l8w194XyHRR tdDJBYcr69wtDce6UYhzu9Cs92/SfhvwVHRpdFE93iq53G/6qiACQPFOq+CUeJ0otRsC Z2go6SVQijgiF+pcxHFjeFie7LnlOOmkO6Naa6W8ohxQYeSfdk6HWrFj4KFPrUJfyERm tbuyRR5gyeBemCwxgJTbEJZ33cbooISzzepcX4BUHh/zH/tA34dpdHJbV9zpAoIUD3Hj 87qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=xFQucDSeIky6RZJm1H0SPJFqxE8R+gB7potxyvQnxrg=; b=asyFHRG4H44GfbrAhMurIqKowj6rK1XiXcW+EFsF+GbZMtKw/im10GbaW5W3x6EliY A0JAII3ddtX9/UL7u7Z/TtdU3cdxCC8aoF9ubg6kMeyPBcuJuEpyOWb7/WCz9TuKjFNY S9U5a/rzouWHJ8sB1PaQGS3k8FAFpTZd3gEVQj1lJ9sKJw+Op6oh6OTXjYhB2pOJBaa4 /8vR0xSKL2c2mnXIASpoLnZkjHBKXDH6z2eKUzFDT48OJ26oUfE7v+tvf0/DgWqPBjFL L0hyxrRuyTcP+OP+4xR4Q2ipise8yJbgojTrzVWnGz0M04/B/cxUL0Ry71dxvRt03lVI 7HgQ== X-Gm-Message-State: AOAM532c7Mo1NxVE8Amn6jGRK5cwzNHK6VR3Oa1uFWMMPD0++g74XLWV MBsT+jDzDCxyWzegbOSvMif8TeFFmyFVr4KseX2lzNxs/j8= X-Google-Smtp-Source: ABdhPJyheF59bZFU8SG96GOeDdvU8QfTa26dFa9EXR4neRqN2EHBs6BYIGqwVaqq4I8lXBl1Guwl7hWGJwZnar/p0Tg= X-Received: by 2002:a1c:b0c8:: with SMTP id z191mr8378870wme.165.1589793008689; Mon, 18 May 2020 02:10:08 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:adf:e6c7:0:0:0:0:0 with HTTP; Mon, 18 May 2020 02:10:07 -0700 (PDT) In-Reply-To: References: <133678F3-1EA1-446D-9313-F10F23C84936@cpan.org> From: hiro <23hiro@gmail.com> Date: Mon, 18 May 2020 11:10:07 +0200 Message-ID: Subject: Re: 9P2000.s vs 9P2020 vs. ? (Was Re: [9front] Slow cp, support for 9P2000.s) To: 9front@9front.org Content-Type: text/plain; charset="UTF-8" List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: advanced element AJAX over SVG realtime DOM controller 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 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 > >