[prev in list] [next in list] [prev in thread] [next in thread] 

List:       v9fs-developer
Subject:    Re: [V9fs-developer] Make 9p fast
From:       ron minnich <rminnich () gmail ! com>
Date:       2022-02-28 19:50:38
Message-ID: CAP6exY+sjP0YqF27VT8X6d_qSHuYvep_Jj10qZnMJWY_J-hWWQ () mail ! gmail ! com
[Download RAW message or body]

got it. Thanks.

On Mon, Feb 28, 2022 at 11:33 AM Eric Van Hensbergen <ericvh@gmail.com> wrote:
> 
> No, you misunderstood me, the different open mode would only be for the special \
> files so normal files wouldn't need to change anything and then I could do it all \
> over the same mount instead of having different mounts for different purposes which \
> seems...excessive.  But really what I'm probably reacting to is thinking about \
> fresh connections - one could send multiple attaches, but we can't communicate \
> mount options in Tattach just Tverison -- that's arbitrary and could be changed I \
> suppose.  But like you said, the behavior you are defining is client side anyways \
> so we'd just need the client to know whether or not the file was static -- that is \
> something that could be communicated in a Qid - qid.version == 0 is supposed to \
> identify synthetics anyways, so maybe we already have that mechanism. 
> -eric
> 
> 
> -eric
> 
> 
> On Mon, Feb 28, 2022 at 1:25 PM ron minnich <rminnich@gmail.com> wrote:
> > 
> > I want a read/write file system. for reading and writing plain files,
> > and creating directories, that's it. Usage has to be transparent, I
> > can't ask all those linux programs to change their open modes, so that
> > sounds like a mount option to me at least. But I'm still fairly
> > certain we can change client behavior to get what we want. In my view
> > it's all about Tread, which is most packets; and Twrite, which when I
> > measured it was much fewer packets. The rest are much less common, or
> > at least used to be (well OK linux seems to be a bit more anxious to
> > Tstat things?)
> > 
> > btw, fun fact: out of 3M files in my ~, 82% are 16K or less :-); 57%
> > are 4k or less :-) This in a nutshell is why big MSIZE is not always
> > the win it looks. Also from earlier lives, a big issue on writing
> > with. e.g, gnu ld, was its propensity to do lots of 1 or 4 byte writes
> > (not 1 or 4K; one or four BYTE). I put write coalescing into the
> > client in 1998 and it was dramatically better. Your caching would help
> > there.
> > 
> > 
> > ron
> > 
> > On Mon, Feb 28, 2022 at 11:07 AM Eric Van Hensbergen <ericvh@gmail.com> wrote:
> > > 
> > > Well, that's part of my question - there's lots of per-session semantics that \
> > > could be implemented by a synthetic file server that would require server \
> > > coordination to not break.  however, if all you are doing is serving a static \
> > > file system then its less of a concern -- there are obviously ways you can \
> > > screw yourself over, but those can happen outside of the 9p context so playing \
> > > games with caching, read-ahead, and asynchrony don't necessarily leave you in a \
> > > worse spot. 
> > > Contrary to my previous opinion of handling this with protocol/mount options - \
> > > I do wonder if many of these could be achieved with different open modes (which \
> > > a client could choose to make default and we could override when what we were \
> > > accessing was a FIFO or device....) 
> > > On Mon, Feb 28, 2022 at 1:02 PM ron minnich <rminnich@gmail.com> wrote:
> > > > 
> > > > eric, what do you mean by a client? A user or a program or a computer
> > > > or just the FID from a Tmount?
> > > > 
> > > > in any event, I think the fence logic should be in the client and for
> > > > sure should not require any change to servers.
> > > > 
> > > > i.e., servers would not be responsible for serializing on the FID,
> > > > just the client.
> > > > 
> > > > ron
> > > > 
> > > > On Mon, Feb 28, 2022 at 10:55 AM Eric Van Hensbergen <ericvh@gmail.com> \
> > > > wrote:
> > > > > 
> > > > > For Treads, even if folks use them for special things there's nothing to \
> > > > > say we couldn't restrict the new "fast" semantics to a specific version of \
> > > > > the protocol or certain options.  This was implicit with the cache options \
> > > > > (they wouldn't work with devices either). 
> > > > > For fences, are you only considering a single client? That simplifies many \
> > > > > things -- and I guess that's why you are saying you can do it all on the \
> > > > > client. 
> > > > > -eric
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > On Mon, Feb 28, 2022 at 12:31 PM ron minnich <rminnich@gmail.com> wrote:
> > > > > > 
> > > > > > On Sun, Feb 27, 2022 at 2:31 PM <ng@0x80.stream> wrote:
> > > > > > 
> > > > > > > Forgive the naive question, but would this change entail that a
> > > > > > > client may not observe its own writes? (Because the client may send
> > > > > > > Twrite and Tread but the Tread may be served first, I mean.) Isn't that
> > > > > > > undesirable? What do other file systems do?
> > > > > > 
> > > > > > I have thought about this, and think we can resolve it on the client
> > > > > > side with some rules.
> > > > > > 
> > > > > > Treads are considered to be independent of each other and idempotent (NFS \
> > > > > >                 rules)
> > > > > > - This will break for things like mice, sockets, etc. Do we care? Do
> > > > > > people on LInux use
> > > > > > 9p for streaming devices, Unix FIFOs, etc.? In my case, I do not.
> > > > > > 
> > > > > > Twrites act like a fence for Treads, i.e., if there is a Twrite, it
> > > > > > blocks on pending reads, and
> > > > > > new reads block on the Twrite to finish.
> > > > > > 
> > > > > > Tclunk acs like a fence for all pending IO. If there are Twrites, it
> > > > > > blocks on them, else
> > > > > > it blocks on pending reads.
> > > > > > 
> > > > > > Note that: this is all client logic. It is probably logic I will be
> > > > > > testing in Plan 9 in the next few months.
> > > > > > 
> > > > > > A few other notes from a lot of years snooping Plan 9.
> > > > > > 
> > > > > > The first thing everyone does to try to fix 9p slowness is "grow the
> > > > > > MSIZE." This can help, but it can hurt.
> > > > > > 
> > > > > > It can help, in that, basically, for an msize like even 8K, you can
> > > > > > read the entire file in one go.
> > > > > > 
> > > > > > It can hurt, in that, for really big files, with a big delay-bandwidth
> > > > > > product, you're going to get head-of-line blocking:
> > > > > > each Tread will wait on that "really big Tread" before it to finish,
> > > > > > so your time between Treads will be LARGER.
> > > > > > 
> > > > > > The other issue with big MSIZE is that it also limits concurrency over
> > > > > > multiple FIDs, for the same reason: the connection
> > > > > > is not usable for blocks of time as it is moving 1M blocks for one FID.
> > > > > > 
> > > > > > Big block size is an obvious fix with subtle negative impacts.
> > > > > > 
> > > > > > All this I've seen in the wild, on big machines.
> > > > > > 
> > > > > > Anyway, I will try the caching stuff, sounds very interesting, and see
> > > > > > how it impacts my  cpu (github.com/u-root/cpu) command;
> > > > > > 9p performance is critical to that command.
> > > > > > 
> > > > > > Thanks again for the work!
> > > > > > 
> > > > > > ron


_______________________________________________
V9fs-developer mailing list
V9fs-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/v9fs-developer


[prev in list] [next in list] [prev in thread] [next in thread]