9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: dexen deVries <dexen.devries@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] Q: moving directories? hard links?
Date: Fri, 22 Apr 2011 10:27:40 +0200	[thread overview]
Message-ID: <201104221027.40955.dexen.devries@gmail.com> (raw)
In-Reply-To: <20110422080352.DF703B835@mail.bitblocks.com>

On Friday 22 of April 2011 10:03:52 Bakul Shah wrote:
> On Thu, 21 Apr 2011 18:41:25 EDT erik quanstrom <quanstro@labs.coraid.com>  
wrote:
> > > IIRC companies such as Panasas separate file names and other
> > > metadata from file storage. One way to get a single FS
> > > namespace that spans multiple disks or nodes for increasing
> > > data redundancy, file size beyond the largest disk size,
> > > throughput (and yes, complexity).
> > 
> > that certainly does seem like the hard way to do things.
> > why should the structure of the data depend on where it's
> > located?  certainly ken's fs doesn't change the format of
> > the worm if you concatinate several devices for the worm
> > or use just one.
> 
> ?
> 
> It all boils down to having to cope with individual units'
> limits and failures.
> 
> If a file needs to be larger than the capacity of the largest
> disk, you stripe data across multiple disks.  To handle disk
> failures you use mirroring or parity across multiple disks.
> To increase performance beyond what a single controller can
> do, you add multiple disk controllers.  When you want higher
> capacity and throughput than is possible on a single node, you
> use a set of nodes, and stripe data across them. To handle a
> single node failure you mirror data across multiple nodes. To
> support increased lookups & metadata operations, you separate
> metadata storage  & nodes from file storage & nodes as lookups
> + metadata have a different access pattern from file data
> access. To handle more concurrent access you add more net
> bandwidth and balance it across nodes.

<![RANT[
except those are not 100% orthogonal. not in theory, and even less in 
implementations. you risk ending up with big-ball-of-mud code, or abstracting 
all your performance (and flexibility and metadata like S.M.A.R.T.) away.

also, (almost every) network hop and node lessens the compound reliability; 
some even introduce entirely new failure modes.
]]>

so kudos to Isilon for actually having build great stuff :)


-- 
dexen deVries

[[[↓][→]]]

``In other news, STFU and hack.''
mahmud, in response to Erann Gat's ``How I lost my faith in Lisp''
http://news.ycombinator.com/item?id=2308816



  reply	other threads:[~2011-04-22  8:27 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-16  2:36 smiley
2011-04-16  2:40 ` Jacob Todd
2011-04-16  4:22 ` ron minnich
2011-04-16 16:53   ` erik quanstrom
2011-04-16 17:33   ` smiley
2011-04-16 17:51     ` erik quanstrom
2011-04-21 15:32       ` smiley
2011-04-21 15:43         ` ron minnich
2011-04-16 18:22     ` Bakul Shah
2011-04-21 15:44       ` smiley
2011-04-21 15:49         ` ron minnich
2011-04-21 16:54         ` Bakul Shah
2011-04-21 20:17           ` Richard Miller
2011-04-21 21:10             ` Bakul Shah
2011-04-21 22:41               ` erik quanstrom
2011-04-21 23:17                 ` ron minnich
2011-04-21 23:54                   ` Bakul Shah
2011-04-21 23:55                   ` erik quanstrom
2011-04-22  0:01                     ` ron minnich
2011-04-22  0:04                       ` erik quanstrom
2011-04-22  8:03                 ` Bakul Shah
2011-04-22  8:27                   ` dexen deVries [this message]
2011-04-22 13:05                   ` erik quanstrom
2011-04-22 17:47                     ` Bakul Shah
2011-04-24 18:58                       ` erik quanstrom
2011-04-16 18:03   ` Richard Miller
2011-04-16 18:17     ` Skip Tavakkolian
2011-04-16 18:56       ` Rob Pike
2011-04-18  9:08         ` Aharon Robbins
2011-04-18 12:41           ` erik quanstrom
2011-04-18 12:59             ` Lucio De Re
2011-04-18 13:00               ` erik quanstrom
2011-04-18 13:11                 ` Lucio De Re
2011-04-23  3:48                   ` Ethan Grammatikidis
2011-04-21  9:22       ` Balwinder S Dheeman
2011-04-16 16:58 ` erik quanstrom
2011-04-19 15:36 ` Charles Forsyth

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=201104221027.40955.dexen.devries@gmail.com \
    --to=dexen.devries@gmail.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).