RE: smartdrive für linux ?!? Gibts das vieleicht....?
![](https://seccdn.libravatar.org/avatar/3a93d3aa76b504280bdbafec3437f7c5.jpg?s=120&d=mm&r=g)
Hallo Leute!
-----Original Message----- From: Peter Wiersig [mailto:wiersig-ml@dns.glamus.de] Sent: Dienstag, 28. Januar 2003 13:54 To: Suse-Linux (E-mail) Subject: Re: smartdrive für linux ?!? Gibts das vieleicht....?
Scheufen Stephan wrote:
Hallo Linux Gemeinde! sagt mal, weis einer von euch ob es soetwas wir SMARTDRV auch für Linux gibt....?
Ich benötige ein PlattenCache um Plattenzugriffe auf einem ReiserFS oder XFS zu beschleunigen, (...)
Hintergrund: ein Rsync Server der 6gb Daten enthält und an den sich 108 andere Rsync Server andocken um diese Daten zu täglich ziehen. Anmerkung: ich benutze dabei den CRC und kann auf den nicht verzichten...
Dir wuerde selbst ein SMARTDRV nicht helfen (Es sei denn, du haettest mehr als 6GB Hauptspeicher), weil beim Mirroring ja alles sequentiell lesen musst. Jeder Cache ist da irgendwo fehl am Platze.
Wie hast du deine Festplatten organisiert? Meiner Meinung nach muesstest du mit einem "Stripe"-Verfahren arbeiten um eine hohe Lesegeschwindigkeit zu erzielen.
Hast du die mount-Option "noatime" gesetzt? Das sorgt dafuer, das nicht auch noch Daten geschrieben werden muessen, wenn deine Mirrors zugreifen. Bei einem Filearchiv sollte das auch funktionieren.
Hast du schon ermittelt, ob dein Flaschenhals ueberhaupt am Durchsatz des Plattenspeichers liegt? CRC klingt CPU-Zeit hungrig.
Peter
Die Idee mit dem Stripe hatte ich auch schon und werde das machen sobald ich eine zweite Maschine dafür habe! Dann werde ich auch soviele HDDs wie möglich reinhängen (können dann ja auch kleine sein, denn die Anzahl der HDDs beim lesen sind ja wichtig), damit sich die HDDs den LeseVorgang teilen. Wir haben in der Maschine schon 1gb RAM und eine 1,4ghz CPU und die langweilt sich, auch wenn die 108 Maschinen ihre Filelists bauen....aber die HDDs sind auf "dauerlicht" geschaltet! Die Option "Noatime" kenne ich noch nicht, werde die aber ausprobieren. Gibt?s dort Datenverlustrisiko? Frage@Falk: warum sollte das ext2 schneller sein? in unseren Tests (zT mit Bonnie) war es dem ReiserFS klar unterlegen...(bitte keine Glaubenskriege hier ;-) sondern technische Pros/Kons bitte... gruss Stephan (der-jetzt-"noatime"-testen-wird)
![](https://seccdn.libravatar.org/avatar/02bd3b8e3a436c5b5dac0042a9a9fa6b.jpg?s=120&d=mm&r=g)
Hi Stephan, Scheufen Stephan schrieb:
Frage@Falk: warum sollte das ext2 schneller sein? in unseren Tests (zT mit Bonnie) war es dem ReiserFS klar unterlegen...(bitte keine Glaubenskriege hier ;-) sondern technische Pros/Kons bitte...
kein Glaubenskrieg, Messwerte. auf einem Einprozessorsystem mit aktueller CPU ist Reiser hier nur ein klein wenig langsamer als ext2, auf einer 4x700MHz XEON Maschine mit 4GB Hauptspeicher ist Reiser je nach Testbedingung zwischen 10 und 60 mal langsamer als ext2. Aus Zeitgründen hab ich den XFS Test auf der Kiste noch nicht gemacht. Beim Dauertransfer bringt ein ext2 auf einem icp-vortex RAID5 5x32GB auf dieser Maschine die erwarteten 50-55MB/s lesen/schreiben, reiser dagegen nur 2,5MB/s schreiben und max. 5MB/s lesen im allerbesten Fall. Wenn der Transfer komplett in den BS-Cache läuft ist reiser genauso langsam, 256MB file schreiben 271s, bei ext 2 waren es dagegen nur 4,5s. Wenn es in den controller cache passt sind es bei ext2 für 100MB nur 1.02s read und 1.05s write. Bei Reser war völlig wurscht wie gross oder klein die Datei war, es war immer viel zu langsam. Frag mich bitte nicht welche üblen Faktoren hier zusammen laufen, aber fakt ist das ich das so gemessen habe und exact nichts aussser dem Filesystem geändert habe. Der Kernel ist ein 2.4.20 Vanilla, alles aktuelle aus dem Hause SuSE läuft wegen diesem ACPI !"%§%!%$ auf der Maschne eh nicht. PS: ich habs soooo satt im Moment mich weiter damit zu beschäftigen, ext2 hat das Problem erstmal gelöst, vielleicht bin ich ja auch nur zu doof für reiser. MfG. Falk
participants (2)
-
Falk Sauer
-
Scheufen Stephan