Linux software Raid, excellente implementatie !

[XTerm]

Waarschuwing: onderstaand stukje is niet geheel vrij van opschepperij

Okay, na ong 3 dagen werk marcheert mijn Gentootje terug zoals IK het
wil. De harddisklayout is krankzinning, maar werkt fantastisch :

De hardware :

code:

hda: Maxtor 6Y060L0, ATA DISK drive
hdb: Maxtor 33073H3, ATA DISK drive
hde: MAXTOR 6L040J2, ATA DISK drive
hdg: MAXTOR 6L040J2, ATA DISK drive

Hda is de zwaarste schijf, een 60 gig maxtor aan 7200 rpm, met "Liquid
bearing", zeer moeilijk te krijgen in la Belgique.
Dan Hdb is een simpele betrouwbare 5400 rpm Maxtor.
Hde en g zijn ook 7200 rpm Maxtors (UDMA 133) type 740Dx

code:

hda: 120103200 sectors (61493 MB) w/2048KiB Cache, CHS=7476/255/63, 
hdb: 60032448 sectors (30737 MB) w/2048KiB Cache, CHS=3736/255/63, 
hde: 78177792 sectors (40027 MB) w/1820KiB Cache, CHS=77557/16/63
hdg: 78177792 sectors (40027 MB) w/1818KiB Cache, CHS=77557/16/63

Mijn mobo heeft slechts support voor UDMA 100 mor enfin maakt niet uit


Partitielayout is redelijk ingewikkelt.

Eerst en vooral, root partitie is een raid0 (stripe) van 3x6Gb partities
op de 7200 rpm schijven. Verder heeft elke 7200 rpm schijf 256 swap ook
gestriped. Een kleine /boot op /dev/hda1 om geen boot problems te
hebben. De 2de stripe is voor DivX'en en andere brol op te slaan waar
het rap moet gaan: een stripe van 2x20 Gb op hde en g. De /home is een
10 gig partitie op /dev/hda, in Raid1 met een even grote partitie op
hdb. (just in case...) De rest zijn gewoon losse partities (voor de
moment zonder doel )

df -Th:

code:

root@anubis len # df -Th
Filesystem    Type    Size  Used Avail Use% Mounted on
/dev/md0      ext3     17G  2.7G   13G  17% /
tmpfs        tmpfs    1.0M  156K  868K  16% /mnt/.init.d
/dev/md2      ext3    9.6G  135M  8.9G   2% /home
/dev/hdb6     ext3     19G   33M   17G   1% /mnt/bck
/dev/hda7     ext3     26G   33M   24G   1% /mnt/std3
/dev/hda9     ext3     14G   33M   13G   1% /mnt/std4
/dev/hde8     ext3     12G  8.5G  3.2G  73% /mnt/std1
/dev/hdg8     ext3     12G  7.5G  4.2G  64% /mnt/std2
/dev/md1      ext3     37G  3.1G   31G   9% /mnt/fmed

cat /proc/mdstat

code:

Personalities : [linear] [raid0] [raid1] [raid5]
read_ahead 1024 sectors
md2 : active raid1 ide/host0/bus0/target1/lun0/part5[1]
ide/host0/bus0/target0/lun0/part8[0]
      10241280 blocks [2/2] [UU]

md0 : active raid0 ide/host2/bus1/target0/lun0/part5[2]
ide/host2/bus0/target0/lun0/part5[1]
ide/host0/bus0/target0/lun0/part5[0]
      18433024 blocks 256k chunks

md1 : active raid0 ide/host2/bus1/target0/lun0/part7[1]
ide/host2/bus0/target0/lun0/part7[0]
      39100416 blocks 1024k chunks

unused devices: <none>

Allemaal goed en wel, maar gisteren kwam ik tot de vaststelling dat als
ik ook maar iets deed dat een beetje hd intensief was, dat ik loads van
10+ kreeg en de welbekende stotterende muis daarbij (een kleine
teleurstelling na 3 dagen werk).

Wat rondprutsen op internet en jawel :

code:

hdparm -c1d1X69 /dev/hda
hdparm -c1d1X69 /dev/hde
hdparm -c1d1X69 /dev/hdg
hdparm -c1d1X68 /dev/hdb

X69=UDMA100 X68=UDMA66

Sindsdien, alles ongelooofelijk smooth, een benchmarkje in /tmp geeft
deze resultaten :

code:

anubis root # bonnie++ -d /tmp -u 0
Version 1.02c       ------Sequential Output------ --Sequential Input-
--Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block--
--Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP 
/sec %CP
anubis        1512M 14177  97 51826  40 22697  18 20506  96 75361  33
389.6   1
                    ------Sequential Create------ --------Random
Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read---
-Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP 
/sec %CP
                 16   884  98 +++++ +++ +++++ +++   950  99 +++++ +++ 
2468  98

Even kort, een schrijfsnelheid van 50Meg/sec en leessnelheid van
70Meg/sec
Het enige wat blijkt is dat ext3 nogal CPU intensief is, maar ik denk
niet dat ik daar ooit last van ga hebben

De informatie over Software Raid vind je hier :
http://www.tldp.org/HOWTO/Software-RAID-HOWTO.html

Dit kan voor alle kernels sinds 2.2.x , maar een 2.4.x is wel aan te raden.
Ik weet niet of de BSD gebruikers dergelijks hebben ?

[Verwijderd]

mooi rapportje

[CyBeR]

nice, volgende stap-> Software SCSI RAID, en daarna naar hardware SCSI RAID he

(ik blijf er bij dat IDE in het algemeen niet geschikt is voor machines die meer dan een taak tegelijk uit kunnen voeren )

[JJJ]

Hmm, dat mouseprobleem heb ik nu ook lichtelijk last van. Zou dat te fixen zijn met die tip van jou? (* JJJ used geen raid).

[Arzie]

Hmm, heb hier even naar -c en -d van m'n schijf gekeken en die hadden dus netjes alles op 16-bit en DMA uit staan? Terwijl ik in kernel use dma if available enzo gebruik. Maargoed, nu staat het aan en zou het wat smoother moeten lopen. Bij SCSI kan je het niet instellen, dus m'n Linuxpartitie liep al goed.

Maar even ontopic, dat software RAID is dus best leuk! Kost je denk ik net zoveel CPU als bij een goedkoop IDE-RAID kaartje..

[Wilke]

Yep da's zeker leuk, en je hoeft alleen maar 2 (liefst gelijke) harde schijven hebben om lekker snel data te kunnen pompen.

Enneh...als je RAID-0 gebruikt, niet vergeten backups te maken he!

[XTerm]

Wilke schreef op 16 september 2002 @ 23:10:
Yep da's zeker leuk, en je hoeft alleen maar 2 (liefst gelijke) harde schijven hebben om lekker snel data te kunnen pompen.

Enneh...als je RAID-0 gebruikt, niet vergeten backups te maken he!

Op de raid 0's staat enkel zooi, /home staat veilig

Verder is het ALTIJD aan te raden om te hdparmen, meestal staat je hd op een trage PIO mode. Als je dit niet veranderd dan VREET de hd gewoon CPU

[Verwijderd]

Kan software-raid ook met verschillende types harde schijven?!

*Erik zijn oude 20 Gig, 3 Gig, 3,2 Gig en 2 Gig schijven pakken gaat*

[XTerm]

Verwijderd schreef op 17 september 2002 @ 09:09:
Kan software-raid ook met verschillende types harde schijven?!

*Erik zijn oude 20 Gig, 3 Gig, 3,2 Gig en 2 Gig schijven pakken gaat*

Jazeker, je zou bijvoorbeeld een Raid 0 kunnen maken van die 3 gig schijven en die gebruiken om een 6 gig partitie op de 20 gig te mirroren.

Alle combinaties zijn mogelijk, niets houdt je tegen om een raid array als device in een andere te gebruiken

Stel dat je 25 SCSI schijven hebt kan je van clustertjes van 5 een Raid 5 maken en dan die clustertjes in een Raid 0 of 5 steken. Zeer redundant en ziekelijk snel.

[Wilke]

'Niets houd je tegen' behalve dan dat als er dan eentje crasht je meteen goed de lul bent, en dat het dan verscheidene malen overhead kost.

nog iets: als je een schijf hebt van 20 en een van 60, wordt de raid-partitie 40 GB (als ik het goed heb begrepen) en houd je nog 40 GB over op die 60 GB schijf. Je kunt het dus niet 'gewoon' aan elkaar plakken...of wel?

[Zwelgje]

Wilke schreef op 22 september 2002 @ 18:38:
'Niets houd je tegen' behalve dan dat als er dan eentje crasht je meteen goed de lul bent, en dat het dan verscheidene malen overhead kost.

nog iets: als je een schijf hebt van 20 en een van 60, wordt de raid-partitie 40 GB (als ik het goed heb begrepen) en houd je nog 40 GB over op die 60 GB schijf. Je kunt het dus niet 'gewoon' aan elkaar plakken...of wel?

ja hoor je kan ook partities aan elkaar plakken, (linear append mode) het werkt alleen wel ietsjes anders als raid 0....

data wordt dan eerst op de 1e disk geschreven en pas als ie vol is pakt ie de 2e... maw: geen performancewinst..

[XTerm]

Wilke schreef op 22 september 2002 @ 18:38:
'Niets houd je tegen' behalve dan dat als er dan eentje crasht je meteen goed de lul bent, en dat het dan verscheidene malen overhead kost.

nog iets: als je een schijf hebt van 20 en een van 60, wordt de raid-partitie 40 GB (als ik het goed heb begrepen) en houd je nog 40 GB over op die 60 GB schijf. Je kunt het dus niet 'gewoon' aan elkaar plakken...of wel?

Je hebt ook append mode, die gewoon aan elkaar plakt
Verder geloof ik , maar ben niet zeker, dat raid 0 ook werkt @ 80 gig en dat gewoon de laatste 20 gig van die 60 gig schijf niet geaccelereerd wordt.

En met een Raid 5 als een schijf crasht ben je NIET de lul, want de kernel gaat bij de volgende boot onmiddelijk je stripe herstellen en als je een hotspare drive(s) hebt ingesteld gebeurt dit zelfs onmiddelijk.