9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Jack Norton <jack@0x6a.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] Petabytes on a budget: JBODs + Linux + JFS
Date: Tue,  8 Sep 2009 11:53:39 -0500	[thread overview]
Message-ID: <4AA68C13.7080400@0x6a.com> (raw)
In-Reply-To: <8ffbc6e3c9f6feb54b460e55037cde32@quanstro.net>

erik quanstrom wrote:
>> I think what he means is:
>> You are given an inordinate amount of harddrives and some computers to
>> house them.
>> If plan9 is your only software, how would it be configured overall,
>> given that it has to perform as well, or better.
>>
>> Or put another way: your boss wants you to compete with backblaze using
>> only plan9 and (let's say) a _large_ budget.  Go!
>>
>
> forgive me for thinking in ruts ...
>
> i wouldn't ask the question just like that.  the original
> plan 9 fileserver had a practically-infinite storage system.
> it was a jukebox.  the jukebox ran some firmware that wasn't
> plan 9.  (in fact the fileserver itself wasn't running plan 9.)
>
> today, jukeboxes are still ideal in some ways, but they're too
> expensive.  i personally think you  can replace the juke
> with a set of aoe shelves.  you can treat the shelves as if
> they were jukebox platters.  add as necessary.  this gives
> you an solid, redundant foundation.
>
> for a naive first implementation targeting plan 9 clients,
> i would probablly start with ken's fs.  for coraid's modest
> requirements (10e2 users 10e2 terminals 10e1 cpu servers
> 10e2 mb/s), i built this http://www.quanstro.net/plan9/disklessfs.pdf
>
> i don't see any fundamental reasons why it would not
> scale up to petabytes.  i would put work into enabling
> multiple cpus. i would imagine it wouldn't be hard to
> saturate 2x10gbe with such a setup.  of course, there is
> no reason one would need to limit oneself to a single
> file server, other than simplicity.
>
> of course this is all a bunch of hand waving without any
> money or specific requirements.
>
> - erik
>
>
Erik,

I read the paper you wrote and I have some (probably naive) questions:
The section #6 labeled "core improvements" seems to suggest that the
fileserver is basically using the CPU/fileserver hybrid kernel (both
major changes are quoted as coming from the CPU kernel).  Is this just a
one-off adjustment made by yourself, or have these changes been made
permanent?
Also, about the coraid AoE unit: am I correct in assuming that it does
some sort of RAID functionality, and then presents the resulting
device(s) as an AoE device (and nothing more)?
Also, another probably dumb question: did the the fileserver machine use
the AoE device as a kenfs volume or a fossil(+venti)?

The reason I am asking all of this is because I have a linux fileserver
machine that _just_ serves up storage, and I have a atom based machine
not doing anything at the moment (with gbE).  I would love to have the
linux machine present its goods as an AoE device and have the atom based
machine play the fileserver role.  That would be fun.
Thanks in advance for patience involving my questions :)

-Jack




  reply	other threads:[~2009-09-08 16:53 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-04  0:53 Roman V Shaposhnik
2009-09-04  1:20 ` erik quanstrom
2009-09-04  9:37   ` matt
2009-09-04 14:30     ` erik quanstrom
2009-09-04 16:54     ` Roman Shaposhnik
2009-09-04 12:24   ` Eris Discordia
2009-09-04 12:41     ` erik quanstrom
2009-09-04 13:56       ` Eris Discordia
2009-09-04 14:10         ` erik quanstrom
2009-09-04 18:34           ` Eris Discordia
     [not found]       ` <48F03982350BA904DFFA266E@192.168.1.2>
2009-09-07 20:02         ` Uriel
2009-09-08 13:32           ` Eris Discordia
2009-09-04 16:52   ` Roman Shaposhnik
2009-09-04 17:27     ` erik quanstrom
2009-09-04 17:37       ` Jack Norton
2009-09-04 18:33         ` erik quanstrom
2009-09-08 16:53           ` Jack Norton [this message]
2009-09-08 17:16             ` erik quanstrom
2009-09-08 18:17               ` Jack Norton
2009-09-08 18:54                 ` erik quanstrom
2009-09-14 15:50                   ` Jack Norton
2009-09-14 17:05                     ` Russ Cox
2009-09-14 17:48                       ` Jack Norton
2009-09-04 23:25   ` James Tomaschke
2009-09-14 16:43 erik quanstrom
2009-09-20 20:13 ` Bakul Shah
2009-09-21  3:37   ` erik quanstrom
2009-09-21 17:43     ` Bakul Shah
2009-09-21 18:02       ` erik quanstrom
2009-09-21 18:49         ` Wes Kussmaul
2009-09-21 19:21           ` erik quanstrom
2009-09-21 20:57             ` Wes Kussmaul
2009-09-21 22:42               ` erik quanstrom
2009-09-22 10:59             ` matt
2009-09-21 19:10         ` Bakul Shah
2009-09-21 20:30           ` erik quanstrom
2009-09-21 20:57             ` Jack Norton
2009-09-21 23:38               ` erik quanstrom
2009-09-21 22:07             ` Bakul Shah
2009-09-21 23:35               ` Eris Discordia
2009-09-22  0:45                 ` erik quanstrom
     [not found]               ` <6DC61E4A6EC613C81AC1688E@192.168.1.2>
2009-09-21 23:50                 ` Eris Discordia

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4AA68C13.7080400@0x6a.com \
    --to=jack@0x6a.com \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).