Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!cica!tut.cis.ohio-state.edu!cs.utexas.edu!chinacat!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F. Haugh II)
Newsgroups: comp.unix.wizards
Subject: Re: bigger longs (64 bits)
Message-ID: <17902@rpp386.cactus.org>
Date: 10 Feb 90 17:05:00 GMT
References: <11071@encore.Encore.COM> <4812@amelia.nas.nasa.gov> <11083@encore.Encore.COM> <605@bbxsda.UUCP> <4849@amelia.nas.nasa.gov>
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Organization: Lone Star Cafe and BBS Service
Lines: 33

In article <4849@amelia.nas.nasa.gov> truesdel@sun217..nas.nasa.gov (David A. Truesdell) writes:
>A striped (or stripeing) filesystem is one in which the filesystem is spread
>out over a set of disks in order to increase capacity and/or performance and/or
>reliability.  The filesystem I'm testing would be classed as "level 5 RAID".
>(That's "Redundant Array of Inexpensive Disks", too bad our disks can't really
>be called "Inexpensive".)

I think you've described three different types of file system schemes.

Striping, from what I've seen, refers to laying consecutive cylinders out
on consecutive drives so that a seek on one drive can occur at the same
time as the transfer on the next drive, thus, seeks are free for sequential
reads.

Another strategy is mirroring, which puts redundant copies of the data
on one or more drives [ usually more than one ] to increase the realiability
of the data.  A drive system with two 50,000Hr MTBF drives mirroring each
other would have a MTBF of decades or centuries instead of years.  A failed
drive could be powered down and replaced without the need to re-boot the
entire system, provided the hardware permitted drive replacement with the
power on.

The simplest reason to use more than one drive is to create a filesystem
larger than any of the single drives involved.  I've seen this refered to as
"spanning".  The beginning of one drive is the logical end of the previous
drive.  Thus, two 250MB drives could be combined to make a single 500MB
logical drive, and so one.

Device drivers for all of these schemes are fairly trivial once the
underlying physical device driver is written.
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: jfh@rpp386.cactus.org