From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Wed, 17 Aug 2011 07:32:40 -0700 Message-ID: From: John Floren To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Help with two small shared file servers Topicbox-Message-UUID: 13ce38a6-ead7-11e9-9d60-3106f5b1d025 On Wed, Aug 17, 2011 at 7:11 AM, Anthony Sorace wrote: > On Aug 17, 2011, at 6:09 AM, Aram H=C4=83v=C4=83rneanu wrote: > >> Can anyone shed some light on why I might want one and not the other? >> Are there any other options? > > ken's fs is a kernel, and essentially gives you a 9p-accessible file stor= age > appliance. it takes another box to be able to run it. #k is part of the s= tandard > cpu server kernel, and is typically used in conjunction with fossil and/o= r > venti. really, you usually want to decide between Ken's fs and fossil (wi= th or > without venti). the basics: > > Ken's FS used to be the default file server in Plan 9. It's a kernel, and= takes over > a box. It is only directly accessible via 9p and il, which pretty much me= ans via > Plan 9 (cpu servers can share the resources as they like, of course). It = does > automatic daily archives of the whole system. It does limited de-duplicat= ing. > It is very fast and extremely stable. > > fossil is a newer file server, designed for use with venti (but usable on= its own, > as well). it can be configured to do daily archives and/or periodic ephem= eral > snapshots (you pick how often and how long they last). It can be used sta= nd- > alone (can't do archives that way, but can still do snapshots) or with ve= nti, in > which case you get venti's block-level deduplication (and direct access t= o > block-level storage). fossil performs reasonably and is relatively stable= , but > less so than ken's fs (and, personally, seems more sensitive to unexpecte= d > shutdown). venti is very stable. typically, if fossil goes belly-up, you = can > reconstruct it from venti (in every case i've seen). > > personally, if you (a) have the extra box to spare, (b) can put in a litt= le extra > work up front, (c) don't care about direct access to block-level storage,= and > (d) can live without ephemeral snapshots, i'd suggest ken's fs; otherwise= , i'd > suggest fossil backed by venti. > >(note that (d) above is slightly tricky, as the ephemeral snapshots in fos= sil >seem to trigger a bug that causes fossil to hang periodically; most report= s >have that happening every ~2 months or so) Ken's FS serves only 9P and can be a hassle to set up and get going. In my opinion, if you can live without ephemeral snapshots, just run fossil+venti with snapshots turned off, which should eliminate the stability complaint. I ran Ken's FS for a while, but in the end it wasn't worth the extra trouble. We're back with fossil + venti now, with fossil on the local disk and Venti on a 16 TB Coraid. >> Is 9p suitable for this? How will the 40ms latency affect 9p operation? > > i expect that'll be well low enough for most uses. > It's going to be slow. See my thesis (https://bitbucket.org/floren/tstream/src/67c7419ad84a/documents/Thesis.pdf= ) for details, but I'd expect file transfers to be at least 6 times slower than transferring via HTTP. When I tested 9P vs. HTTP over connections with 25 ms latency (50ms RTT), I saw a 4x slowdown versus HTTP. Even at 15 ms RTT, transfers took twice as long. John