From: Joshua Wood <josh@utopian.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ata drive capabilities
Date: Wed, 26 Dec 2007 22:22:17 -0800 [thread overview]
Message-ID: <D17C1450-7593-45D1-A96C-A8E3962BF858@utopian.net> (raw)
[-- Attachment #1: Type: text/plain, Size: 1922 bytes --]
> i don't know. if you lean that direction, then the only thing raid
> gives
> you is reduced downtime.
On reflection, it seems I do lean that direction, and generally use
raid mainly to dodge downtime. Our plan 9 systems (and `other' alike)
mostly have redundant disks (when they must have them at all) -- but
they have regular offsite backup also. I wonder if I'm being wasteful.
> i think of raid as reliable storage. backups are for saving one's
> bacon in
> the face of other disasters. you know, sysadmin mistakes,
> misconfiguration,
> code gone wild, building burns down,
>
meteorite! ;)
> (and if my experience with backups is any indiciation, it's best
> not to
> rely on them.)
>
Probably another discussion, but I try to deal with this by testing
the offsite backups (rdarena output) of the plan9 fileserver against
a similar system that's designated the second-string fileserver. I
haven't had to do it in production in a while, (raid narrowed the
reasons I'd need to) so maybe I'm missing something and it would be
less successful than in the testing.
> but this thinking is probablly specific to how i use raid. i
> imagine the
> exact answer on what raid gives you should be worked out based on
> the application.
>
I probably veer toward mere semantics, but I'd still define your use
of raid to be uptime-protection. The list of exceptions you place
under ``backups are for...'' is the same list, essentially, that
motivates the offsite backups I mention -- the usual holes in the
raid prophylactic. I see how Plan 9 facilities (esp. dump) ameliorate
some of them: admin mistakes, for example. But it doesn't fireproof
the system.
Or, put another way, you're not asserting you have no backup beyond
that fileserver raid, are you? Because if so, I want to learn how I
can skip that step, too.
--
Josh
[-- Attachment #2: Type: text/html, Size: 3013 bytes --]
next reply other threads:[~2007-12-27 6:22 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-27 6:22 Joshua Wood [this message]
2007-12-27 7:28 ` erik quanstrom
-- strict thread matches above, loose matches on Subject: below --
2007-12-27 9:01 Joshua Wood
2007-12-27 15:15 ` Brantley Coile
2007-12-26 16:22 Joshua Wood
2007-12-26 18:14 ` erik quanstrom
2007-12-26 7:44 Joshua Wood
2007-12-26 13:18 ` roger peppe
2007-12-26 18:15 ` erik quanstrom
2007-12-25 21:40 Christian Kellermann
2007-12-25 21:48 ` Pietro Gagliardi
2007-12-25 23:59 ` erik quanstrom
2007-12-26 6:31 ` ron minnich
2007-12-26 13:10 ` erik quanstrom
2007-12-26 19:52 ` Christian Kellermann
2007-12-26 20:13 ` andrey mirtchovski
2007-12-27 18:12 ` Christian Kellermann
2007-12-26 23:58 ` Robert William Fuller
2007-12-27 2:34 ` erik quanstrom
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=D17C1450-7593-45D1-A96C-A8E3962BF858@utopian.net \
--to=josh@utopian.net \
--cc=9fans@cse.psu.edu \
/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).