Am 2005-05-14 18:15:47, schrieb Gerhard Wolfstieg:
>      Hallo,

> ->  nur noch Platten mit mindestens 8 MB RAM

Naja, ist empfehlenswert, wennD u viele Zugriffe hast,

Mein kleiner CyberCenter Webserver macht monatlich nicht mehr
als 8 Gbyte Traffic, was pro Tag dann rund 270 Mbyte sind oder
pro Stunde eben 11,2 MByte.

Wenn die HTML-Seiten oder Images durchschnittlich 5 kByte haben
w�hren das gerade mal 38 Requests pro Minute.

Da brauchste auch keine Cache.

Wenn ich dann allerdings den Presiunterschied von 3-5 � sehe,
w�rde ich dann wohl doch die 8MB nehmen.  :-)

> ->  bei heutigen Platten ist die reine Lesegeschwindigkeit zu
> vernachl�ssigen, wenn nicht h�ufig unfragmentierte Dateien ab (grob) 50

Vor allem �bers Netzt, denn die meisten verwenden 100 MBit
und vieleicht FullDupex das sind 7-16 MByte pro Sekunde und
mittlerweile gibt es keine Platte mehr die weniger als
50 MByte pro Sekunde schaufelt.

> MB Gr��e betroffen sind. Da spielt die Zugriffszeit allein die
> entscheidende Rolle. Daraus folgt a) lieber mehr kleinere Platten als

Also ich habe ein gewaltiges Maildir, was ich von den "/home/*/Maildir"
als Symlink auf ne SATA Raptor mit 36 GByte auslagern will (entscheidung
ist heute gefallen).  Raid ben�tige ich nicht, aber mein Mainboard hat
zwei SATA Anschl�sse und ich will den Test machen.

> (eine) gro�e, weil die mittlere Zugriffszeit bei kleinen sonst
> baugleichen niedriger ist  b) wegen Zuverl�ssigkeit, L�rm und Temperatur

Stimmt nicht ganz, denn es gibt Festplatten die haben 120 GByte
und nur eine Disk, die IBM/Hitachi 400GByte haben aber vier.

Und die neuen 500er sollen 3 haben, aber mit verbesserter Technik

> sollten nur Platten unter 10000 upm in Frage kommen, weil die hohen
> Umdrehungsgeschwindigkeiten nicht wegen der Zugriffsgeschwindigkeit
> gemacht sind. (Die Vorteile von mehreren kleinen Platten statt einer

Die MITTLERE Zugriffsgeschwindigkeit ist die Zeit, die der HEAD
ben�tigt, um von einen Sektor auf einen anderen �berzugreifen.

Sprich, wenn Du auf Spur 1 zugreifst un der n�chste block der
Datei in Spur eins ist, mu� der HEAD sich �ber 98 Spuren bewegen
um den n�chsten Block der Datei zu lesen = langsamme Zugriffszeit.

Wenn Du ne Platte aussuchen willst, mu�t Du also erstens die
Kapazit�t der DISK wissen, und zweitens die Anzahl der HEADs pro
DISK.  Bei Platten bis 120 GByte wirste aber immer nur eine DISK
antreffen.  Erst 160er habe dann wieder zwei DISKs.

Einige Hersteller haben dazu sehr interessante Informationen.

Anm:    Die Western Digital Raptor mit 36 und 74 Gbyte haben beide
        nur jeweis zwei DISKS und doppelt soviele pysikalische
        HEADs wie eine PATA, weshalb dadurch mittlere Zugrifszeiten
        von 3-4 ms zustande kommen.

> gro�en in stinknormalen Arbeitsplatzrechnern (Spieledosen bis
> Workstations) sind gleich vielfach. Bei Servern mu� man ein bi�chen mehr

Klar, meine MultimediaStation hat auch drei IBM/Hitachi mit
120 GByte und Raid-5... Da kannste gewaltig streamen...

ppmtompeg hat damit keine Probleme und per STOUT/STDIN
1024x768 mit 25 Frames streamen geht auch damit.

> nachdenken, wird mit diesen Gedanken aber auch bessere Entscheidungen
> treffen k�nnen)
> 
> Kann das jemand widerlegen oder erg�nzen?

Hmmm, weis nicht, aber nachdem ich gesehen habe, das einer der
IPC/Vortex die ich lezte Woche auf eBay ergattert habe Raid-50
macht wirds nat�rlich interessant

In nehmen dazu einen meiner 15-Platten K�fige mir 15 mal 9 GByte
fase die als Raid-5 zusammen und Stripe sie...  =>  Raid-50

Bleiben dann mal rund 60 GByte �brig und sollte ne tierische
Zugriffszeit haben plus gleichzeitiger Ausfallsicherheit.

W�rde nur noch gerne wissen wie Raid-50 eigentlich funktioniert,
den habe nichts davon im Internet gefunden.

Die Platten ziehen alle so um die 15 Watt (zus. 225 Watt) und
warm werden sie auch ganz sch�n  :-/

>      Gerhard

Greetings
Michelle

-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
Michelle Konzack   Apt. 917                  ICQ #328449886
                   50, rue de Soultz         MSM LinuxMichi
0033/3/88452356    67100 Strasbourg/France   IRC #Debian (irc.icq.com)

Attachment: signature.pgp
Description: Digital signature

Antwort per Email an