[sclug] RAID 5

Tim Sutton tim at linfiniti.com
Thu Sep 22 10:56:01 UTC 2005


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi

Could I flip the question around a bit and ask :

- - Which distro makes raid configuration easiest (debian based preferably)?
- - How can we set up the raid so that it will boot successfully if any
of the disk fail - we tried to set up /boot on a CF device but were
unable to get debian to boot from it even after getting a CF -> ide ->
sata converter so that all devices on the machine appear to the bios
as sata?
- - What exactly is the difference between the active and inactive
partitions?
- - how can we clone the /boot partition across all disks (Im thinking a
cron job here, but can I clone the mbr to all disks and have the
second in line disk boot if the normal boot drive fails)?
- - can teh boot partition be in the raid? I seem to recall mandrake
used to allow that with its partitioning tool, but Ive never met
another distro that lets me do that...

Many thanks

Regards

Tim

Alex Butcher wrote:

> On Thu, 22 Sep 2005, Keith Edmunds wrote:
>
>> Peter Brewer wrote:
>>
>>> We are running Debian and when we set up the RAID we set all 8
>>> disks to active and none to inactive (not entirely sure whether
>>> we needed an inactive disk or not). All seems to be working
>>> fine except when we simulated a disk failure by booting up with
>>> just 7 disks. Debian detects the missing disk and continues to
>>> boot happily. After I log in, both root and /home seem to be
>>> intact however /data is empty. Why would it successfully
>>> recover just 2 of the 3 RAID partitions when they've all been
>>> set up in the same way?
>>
>>
>> "Recover" is a bit of a misnomer here - it hasn't recovered the
>> partition, merely reconstructed the data from what is left. But
>> maybe I'm being picky, sorry! Anyway, my first thought would be
>> "is the /data partition mounted"? It seems unlikely that all the
>> data would just disappear.
>
>
> Seconded. I would expect an array failure to result in the
> filesystem module bitching about incorrect superblocks and the
> like.
>
>> Keith
>
>
> Best Regards, Alex.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDMo2RWvXTJUo0BDoRAhzyAKCoRnpuuCi985WD+wePptnytnjDSACgqeAw
j7eso89bLlKUUgac4/5WsTQ=
=hpcJ
-----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tim.vcf
Type: text/x-vcard
Size: 116 bytes
Desc: not available
Url : http://lists.tmdg.co.uk/pipermail/sclug/attachments/20050922/fa43a95b/tim-0001.vcf


More information about the Sclug mailing list