From mboxrd@z Thu Jan  1 00:00:00 1970
From: dexen deVries <dexen.devries@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Date: Fri, 22 Apr 2011 10:27:40 +0200
User-Agent: KMail/1.13.6 (Linux/2.6.39-rc3-22+; KDE/4.5.5; x86_64; ; )
References: <255556ff42dac9585ddf5e7f766d7175@hamnavoe.com>
	<9482032322d5daaadceace1f6875dad3@coraid.com>
	<20110422080352.DF703B835@mail.bitblocks.com>
In-Reply-To: <20110422080352.DF703B835@mail.bitblocks.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201104221027.40955.dexen.devries@gmail.com>
Subject: Re: [9fans] Q: moving directories? hard links?
Topicbox-Message-UUID: d24028f4-ead6-11e9-9d60-3106f5b1d025

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=
> =20
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).
> >=20
> > 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.
>=20
> ?
>=20
> It all boils down to having to cope with individual units'
> limits and failures.
>=20
> 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=20
implementations. you risk ending up with big-ball-of-mud code, or abstracti=
ng=20
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;=
=20
some even introduce entirely new failure modes.
]]>

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


=2D-=20
dexen deVries

[[[=E2=86=93][=E2=86=92]]]

``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=3D2308816