From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <600308d605090916023b856b47@mail.gmail.com> Date: Sat, 10 Sep 2005 01:02:46 +0200 From: Francisco Ballesteros To: paurea@gmail.com, Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] reliability and failing over. In-Reply-To: <599f06db050909155055507829@mail.gmail.com> 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> <599f06db050909155055507829@mail.gmail.com> Cc: Topicbox-Message-UUID: 86663ca8-ead0-11e9-9d60-3106f5b1d025 Beware of the latency. Plan B usage shows that latency is the biggest problem. I admit that only in unions, but if you join N different file servers in a directory, and then you dup the latency, it may be a problem. A workaround is just not to join too many servers, but it's a workaround, not a fix. Anyway, when I complete volfs we'll see if it=B4s beareable or not. If it is, I'll be happy to discard the kernel changes. If it's not, we'll have to see why. On 9/10/05, Gorka guardiola wrote: > 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 ke= rnel. > > > It provided failover (on replicated FSs, by some other means) and cou= ld > > > recover the fids justh by keeping track of their paths. >=20 > 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. >=20 > > > > > > The user level process I'm with now is quite similar to that (appart = from > > > including the language to select particular volumes) it maintains a f= id > > > table knowning which server, and which path within the server are the= ones > > > for each fid. It's what the Plan B kernel ns does, but within a serve= r. > > > > > > Probably, the increase in latency you are seeing is the one I'm going= to > > > see in volfs. The 2x penalty in performace is what one could expect, = because > > > you have twice the latency. However, the in-kernel implementation has= no > > > 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? > > > > 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. >=20 > 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. >=20 > 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? :-)). > -- > - curiosity sKilled the cat >