Re: Einfacher SAS Controller

Gerd Truschinski wrote:
> Am 06.05.2011 19:29, schrieb Oliver Fromme:
> > Gerd Truschinski wrote:
> > > Am Wochenende werde ich das Ganze zusammenbauen. Ich will erst einmal
> > > 5x500GB Platten anschließen (4 x Daten plus eine Parity). Die liegen
> > > noch rum. Wenn das einigermaßen Durchsatz ergibt sollen 7x2TB Platten rein.
> > > Hat jemand einen Vorschlag für eine gute Platte? Die WD20EARS sollen ja
> > > wg. der Sektorgröße lügen...
> >
> > Nein, die lügt nicht. Sie verwendet am Host-Interface eine
> > Sektorgröße von 512 Bytes, und genau das meldet sie auch.
> > Intern werden Sektoren mit 4KB Nutzdaten verwendet, aber
> > das ist ja etwas anderes. Das hat nichts mit Lügen zu tun.
>
> Ich finde jetzt nicht die entsprechende Mail, aber im Sommer wurde auf
> der Hackers-Mailinglist darauf hingewiesen, daß die WD bei der
> physikalischen Sektor Größe auch 512Byte statt 4096Byte angibt. Irgend
> was mit "camcontrol ...". Konsens war, daß die Platte nicht nur
> schummelt sonder lügt. Die hatten damit erhebliche Probleme.

Die Werte, die da geliefert werden, würde ich jetzt nicht
überbewerten. Die "echte" physikalische Sektorgröße ist
ohnehin noch größer, da ja nicht nur die reinen Nutzdaten
enthalten sind. Dass einige Festplatten (die EARS ist ja
nicht die einzige) dort 512 angeben, hat sicherlich nur
Kompatibilitätsgründe.

Das Problem ist auch alles andere als neu. Als damals
[im letzten Jahrtausend ;-) ] die MO-Disks mit 2 KB Sektor-
größe aufkamen, hatten einige Betriebssysteme, darunter
FreeBSD, ebenfalls Schwierigkeiten damit, und einige Lauf-
werke boten dann den "rettenden" Jumper, um per Firmware
512-Byte-Sektoren zu emulieren.

Ich persönlich ignoriere den Wert, den die Platte liefert,
völlig, und gehe bei allen Festplatten > 1 TB einfach
pauschal davon aus, dass sie 4 KB Sektoren haben, und
berücksichtige das entsprechend beim Partitionieren und
Formatieren. Selbst wenn sie doch nur 512-Byte-Sektoren
haben, schadet es ja nicht.

Es würde mich übrigens nicht wundern, wenn FreeBSD in ab-
sehbarer Zeit die Default-Fragsize von UFS2 auf 4 KB erhöht
(momentan sind es 2 KB), und die Blocksize entsprechend
auf 32 KB anpasst (derzeit 16 KB), evtl. in Abhängigkeit
von der Größe des Dateisystems und/oder des Devices.

> Nee, das will ich ja gerade nicht! Ich will, daß ihr mir 5 Stunden
> Recherche auf dem Internet erspart und sagt: Die Platte XXX wird bei uns
> mit Erfolg eingesetzt :-)

Gerne: Die Hitachi HDS723030ALA640 wird bei mir mit Erfolg
eingesetzt. :-)

Das ist das 3-TB-Modell mit 7200 rpm aus der "Deskstar"-
Serie, für Dauerbetrieb (24/7) freigegeben. Sie ist nicht
ganz so schnell wie die entsprechende "Ultrastar", aber
auf jeden Fall schneller als die EARS, und Gigabit-Ethernet
kann sie locker saturieren. Ich habe mich für die 7200er
Deskstar (anstelle der Ultrastar) entschieden, da ich Wert
auf geringen Stromverbrauch und Wärmeentwicklung lege, und
außerdem ist sie preisgünstiger. Da ich ebenfalls "nur"
Gigabit-Ethernet habe, genügt die Deskstar für mich völlig.

(Übrigens, auch das Vorgängermodell von Hitachi mit 1 TB
ist bei mir seit geraumer Zeit erfolgreich im Einsatz.)

> > Übrigens, bei sieben Platten sollte man sich überlegen, ob
> > man nicht besser schon zweimal Parity (RAID6) oder, je nach
> > Gusto, einmal Parity und eine Spare-Platte (RAID5) anlegt.
> > Sieben ist eigentlich die Schmerzgrenze für ein RAID5.
>
> Das ist neu für mich. Bisher hatte ich immer 4 Platten, 2x Daten, 1x
> Parity, 1x Spare.

Es gibt natürlich keine feste Regel für das Verhältnis.
Die persönliche "Schmerzgrenze" kann variieren, je nachdem,
worauf man den Schwerpunkt setzt (Sicherheit, Platzeffi-
zienz, Geschwindigkeit). Ich persönlich verwende meistens
bei bis zu fünf Festplatten eine Parity-"Platte", und ab
sechs sind es dann zwei Parity (oder eine Parity und eine
Spare, je nach RAID-Variante).

(Nur für diejenigen, die es ganz genau nehmen: Die Parity-
Daten werden natürlich über alle Festplatten verteilt,
daher schrieb ich Parity-"Platte" in Anführungszeichen.)

Bei vier Platten nur die Hälfte für Daten in einem RAID-5
zu verwenden, find ich schon sehr konservativ. Würde ich
nicht machen, da es weder besonders platzeffizient noch
besonders schnell ist.

> Jetzt habe ich 8 Kanäle. Also 6x Daten und 2x Parity.

Gut, das klingt sinnvoll, wenn es einem wirklich um HA
(High-Availability) geht.

> Spare schenke ich mir dann, da es nur 2 Nutzer gibt und meine Freundin
> den Fileserver sowieso nur als zweiten Backup-Server nutzt. Wenn eine
> Platte abraucht, habe ich alle Zeit der Welt, die auszutauschen.
> Ansonsten ist das mehr ein Spiel.

Naja, man könnte argumentieren, dass RAID daheim sowieso
ein Spiel ist. Ich persönlich verwende RAID nur beruflich,
nicht daheim.

> Und eigentlich sollen die Platten unter ZFS laufen. Gibt es da auch
> ein Problem mit vielen Platten?

Probleme mit vielen Platten sind mir nicht bekannt. File-
Server mit 50 Platten sind durchaus keine Seltenheit.

> Also lieber RAID-Z2 statt RAID-Z?

Wenn Du zwei Parity-Einheiten pro RAID-Set haben möchtest,
musst Du ohnehin RAID-Z2 (RAID-6) nehmen.

Theoretisch könntest Du natürlich auch zwei RAID-Z machen
(jeweils 3+1), aber das reduziert dann wieder die Ausfall-
sicherheit, ohne dass es einen Vorteil brächte.

Vielleicht ist dieser Artikel für Dich interessant:

http://blogs.oracle.com/relling/entry/zfs_raid_recommendations_space_performance

> Außerdem habe ich noch eine 80GB SSD. Da gab es doch eine Möglichkeit
> die als Zwischenspeicher einzusetzen.

Ja, Du könntest den ZIL auf die SSD legen. Das bringt
Performance bei Schreibzugriffen, aber ich glaube nicht,
dass Du davon viel im Alltag daheim merkst. Andererseits,
wenn die SSD ohnehin vorhanden ist, und bevor sie brach-
liegt ... Ich denke aber eher, dass das Gigabit-Ethernet
das Nadelöhr darstellen wird.

> Mein Ziel ist es eine GB-Ethernetleitung auszulasten.

Sollte kein Problem sein, sofern die beteiligten Rechner
schnell genug sind. Bei mir hängt z.B. auch ein kleiner
Atom-Mini-ITX im Netz, der das Gigabit nicht ganz aus-
lasten kann (und leider auch noch kein AHCI am SATA-
Controller unterstützt). Das hat aber nichts mit den
Festplatten zu tun.

> > Und natürlich: Backup nicht vergessen.
>
> Ich habe von meinen einzigartigen Daten Kopien auf der Arbeit, aber
> auch erst nachdem es mal in meiner Wohnung gebrannt hat. Meine
> gesammelten ISOs und MP3s kann ich mir wieder aus dem Netz saugen oder
> von den CDs rippen.

Ja, aber das kostet vermutlich sehr viel Zeit. Muss man
sich sehr genau überlegen. Ich sichere auch die mp3s
meiner CD-Sammlung, denn das Einlesen der CDs (ich besitze
rund 500 Stück) hat durchaus nicht wenig Zeit gekostet.

> Außerdem habe ich 1TB und 2TB USB-Platten für den monatlichen Backup.
> Da dauert ein Restore zwar ein bischen länger, aber was solls.

Ja, ich habe auch eine zeitlang externe USB-Platten für
Backups verwendet.

In jüngerer Zeit bin ich dazu übergegangen, stattdessen
externe Gehäuse mit eSATA zu verwenden. Die gibt es in-
zwischen auch schon relativ günstig (man muss nur aufpassen,
dass man keins erwischt, das nur SATA-150 kann), und der
Geschwindigkeitsgewinn gegenüber USB2 ist enorm. Kann ich
nur empfehlen.

Es gibt natürlich auch USB3-Gehäuse, die theoretisch ebenso
schnell sein müssten. Aber in der Praxis ist das nicht so;
ich habe das einmal ausprobiert: Es ist zwar schneller als
USB2, aber beim Kopieren muss die interne SATA-Platte immer
noch auf die externe USB3-Platte warten. Möglicherweise
liegt es daran, dass der USB-Stack einen größeren Overhead
hat, der zu Latenzen führt. Vielleicht spielt auch eine
Rolle, dass beim "Umweg" über USB bestimmte Features (NCQ)
nicht in der Form genutzt werden können wie bei einer direkt
angeschlossenen Festplatte.

Daher meine Empfehlung, eSATA zu verwenden. Wenn ich eine
neue Festplatte kaufe, kaufe ich sie grundsätzlich doppelt
(manchmal auch dreifach), wobei eine in ein externes eSATA-
Gehäuse gesteckt wird und als Backup dient.

Bei einer 3-TB-Platte dauert ein komplettes Backup (also
die vollständigen 3 TB) via eSATA rund 8 Stunden, d.h. wenn
ich das abends anwerfe, ist es am nächsten Morgen fertig.
Inkrementelle Backups, bei denen nur die Änderungen seit
dem letzten Backup kopiert werden müssen, gehen natürlich
entsprechend schneller, in der Regel nur wenige Minuten,
da sich der größte Teil meiner Daten nicht ändert.

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd
"If you think C++ is not overly complicated, just what is a protected
abstract virtual base pure virtual private destructor, and when was the
last time you needed one?"
        -- Tom Cargil, C++ Journal
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message