From mboxrd@z Thu Jan 1 00:00:00 1970 Mime-Version: 1.0 (Apple Message framework v753) To: 9fans@cse.psu.edu Message-Id: Content-Type: multipart/alternative; boundary=Apple-Mail-1--761478197 From: Joshua Wood Subject: Re: [9fans] ata drive capabilities Date: Wed, 26 Dec 2007 22:22:17 -0800 Topicbox-Message-UUID: 22943e20-ead3-11e9-9d60-3106f5b1d025 --Apple-Mail-1--761478197 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > 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 --Apple-Mail-1--761478197 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

i don't know. =A0if= you lean that direction, then the only thing raid = gives=A0
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. =A0backups are for saving one's bacon in
the = face of other disasters. =A0you know, sysadmin mistakes, = misconfiguration,
code gone wild, building burns = down,=A0

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. = =A0i 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=A0prophylactic. = I see how Plan 9 facilities (esp. dump) ameliorate some of them: admin = mistakes, for example. But it doesn't fireproof the = system.=A0

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

= --Apple-Mail-1--761478197--