From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <599f06db050909155055507829@mail.gmail.com> Date: Fri, 9 Sep 2005 17:50:57 -0500 From: Gorka guardiola To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] reliability and failing over. In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <600308d605090913554224787d@mail.gmail.com> <20050909210534.GI4207@server4.lensbuddy.com> <600308d6050909151067389b35@mail.gmail.com> Topicbox-Message-UUID: 865bd22c-ead0-11e9-9d60-3106f5b1d025 On 9/9/05, Russ Cox wrote: > > Funny. The 9p reliability project looks to me a lot like the redirfs > > that we played with before introducing the Plan B volumes into the kern= el. > > It provided failover (on replicated FSs, by some other means) and could > > recover the fids just by keeping track of their paths. It is almost the same thing. The difference is that one is 9P-9P an the other is 9P-syscall(read-write...). We didnt have a plan 9 kernel on= the other side, so we couldnt use redirfs, that is why we ported recover. It is better for linux (p9p) too, as it doesnt require to mount the filesystem and then use it, so you dont depend on having someone to serve the 9P files by mounting them. I am not sure about Plan 9. On one side, recover knows more about the stuff under it, so it has more granularity, and can fail in a nicer way. On the other side, redirfs is much much simpler. > > > > The user level process I'm with now is quite similar to that (appart fr= om > > including the language to select particular volumes) it maintains a fid > > table knowning which server, and which path within the server are the o= nes > > for each fid. It's what the Plan B kernel ns does, but within a server. > > > > Probably, the increase in latency you are seeing is the one I'm going t= o > > see in volfs. The 2x penalty in performace is what one could expect, be= cause > > you have twice the latency. However, the in-kernel implementation has n= o > > penalty at all, because the kernel can rewrite the mount tables. > > > > Maybe we should talk about this. > > Eric? Russ? What do you say? Is it worth to pay the extra > > latency just to avoid a change (serious, I admit) in the kernel? >=20 > I keep seeing that 2x number but I still don't believe it's actually > reasonable to measure the hit on an empty loopback file server. > Do something over a 100Mbps file server connection > talking to fossil and see what performance hit you get then. Yes, this increase in latency is in the loopback. If you are using a network it is probably completely lost in the noise, the network being probably 100 times slower than the loopback. >=20 > Stuff in the kernel is much harder to change and debug. > Unless there's a compelling reason, I'd like to see it stay > in user space. And I'm not yet convinced that performance > is a compelling reason. I agree, though it depends on the application. For us (normal users) I agree completely that it is not compelling. Some people out there are doing stuff in which performance is important (let them write the code? :-)). --=20 - curiosity sKilled the cat