| View previous topic :: View next topic |
| Author |
Message |
slick
Bodhisattva
Joined: 20 Apr 2003
Posts: 3495
|
 Posted: Mon Apr 06, 2009 6:19 am Post subject: Journaling Filesystem und LVM/Software-Raid (Write Barriers) |
 |
|
Ich habe mich jetzt viel belesen über Software-Raid und Dateisysteme. Allerdings sind mir noch ein paar Dinge unklar.
1) Was sind Write Barriers? Man liest sehr viel darüber, aber irgendwie werde ich da nicht schlau daraus. Auch kommt oft die Aussage man sollte im Zusammenhang lvm/raid (o.ä.) den Write Cache der HD deaktivieren, und es macht Probleme mit XFS usw. Könnte bitte jemand mal in einfachen Worten für DAU erklären, für was gut, was zu beachten usw.
2) Laut Theorie sollte ein Raid 1 beim lesen doppelt so schnell sein wie eine einzelne Platte, ich messe jedoch mit hdparm -tT die gleiche Geschwindigkeit als wie nur von einer Platte (~90 MB/s). Wie kann das sein?
(Mal am Rande, mir kommen auch ~90MB/s (hdparm -tT) für eine neue SATA2 Platte was langsam vor. Sind das normale Werte? Mir fehlt da ein Vergleich)
EDIT: Titel angepaßt weil passender zur Diskussion
Last edited by slick on Wed Apr 08, 2009 8:46 am; edited 2 times in total |
|
| Back to top |
|
 |
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Tue Apr 07, 2009 7:20 am Post subject: |
|
|
Harddisks mit Cache schreiben die Daten in "zufälliger" Reihenfolge auf die Platte. Damit werden so Dinge wie "journaled filesystems" vollkommen sinnfrei, denn die Idee, die Daten zunächst in das Journal zu schreiben (damit ggf. beim Absturz nichts passiert) und erst dann das Journal auf die Platte zu übertragen, kann damit ja nicht funktionieren.
Eine write barrier ist ein spezielles Harddisk-Kommando, das besagt: Schreibe die Daten, die nach diesem Kommando kommen erst dann, wenn alle vorherigen Daten tatsächlich auf der Platte stehen. Der Kernel Device Mapper und vermutlich auch der Kernel Raid (Letzteres habe ich nie probiert) kann aber kein solcher "write barrier"-Kommando bekommen. Ob das technisch prinzipiell nicht möglich ist oder ein fehlendes Feature, weiß ich nicht. Auf jeden Fall geht es nicht, und damit sind Probleme mit allen "journaled filesystems" vorprogrammiert. |
|
| Back to top |
|
|
slick
Bodhisattva
Joined: 20 Apr 2003
Posts: 3495
|
| Posted: Tue Apr 07, 2009 7:41 am Post subject: |
|
|
| Danke, d.h. es sollte reichen entweder das Dateisystem mit nobarrier zu mounten ODER den Write Cache der Platte zu deaktivieren? |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Tue Apr 07, 2009 2:05 pm Post subject: |
|
|
| slick wrote: | | Danke, d.h. es sollte reichen entweder das Dateisystem mit nobarrier zu mounten |
Wenn Du z.B. das ext3/ext4 Filesystem mit barrier=0 mountest (was bei ext3 perverserweise der Default ist), bedeutet das nur, dass es die "barrier"-Kommandos weglässt. (Zumindest bei ext3/4 musst Du die Option gar nicht explizit einstellen, weil das Filesystem automatisch merkt, dass die Kommandos nicht möglich sind). Mit eingeschaltetem Plattencache ist das aber ziemlich blödsinnig, weil Du dann alle Vorteile eines journaled filesystems verlierst. Wenn Du das machst (also mit Plattencache aber ohne barriers arbeiten), nimm lieber ext2: Da hast Du die Vorteile eines journaled filesystems von vornherein nicht und es müssen insbesondere keine unnötigen Daten auf die Platten geschrieben werden um diese Vorteile vermeintlich (aber tatsächlich eben nicht) zu haben. |
|
| Back to top |
|
|
tazinblack
Veteran
Joined: 23 Jan 2005
Posts: 1146
Location: Baden / Germany
|
| Posted: Wed Apr 08, 2009 7:15 am Post subject: |
|
|
| mv wrote: | | slick wrote: | | Danke, d.h. es sollte reichen entweder das Dateisystem mit nobarrier zu mounten |
Wenn Du z.B. das ext3/ext4 Filesystem mit barrier=0 mountest (was bei ext3 perverserweise der Default ist), bedeutet das nur, dass es die "barrier"-Kommandos weglässt. (Zumindest bei ext3/4 musst Du die Option gar nicht explizit einstellen, weil das Filesystem automatisch merkt, dass die Kommandos nicht möglich sind). Mit eingeschaltetem Plattencache ist das aber ziemlich blödsinnig, weil Du dann alle Vorteile eines journaled filesystems verlierst. Wenn Du das machst (also mit Plattencache aber ohne barriers arbeiten), nimm lieber ext2: Da hast Du die Vorteile eines journaled filesystems von vornherein nicht und es müssen insbesondere keine unnötigen Daten auf die Platten geschrieben werden um diese Vorteile vermeintlich (aber tatsächlich eben nicht) zu haben. |
Da stellen sich mir dann diese Fragen :
1. Macht es dann generell keinen Sinn ein journaling filesystem mit einem Softraid (mdadm) zu nutzen, oder muss man es dann nur "speziell" einstellen ( Ich mounte wichtige ext3 - FS mit data=journal)
2. Kann ich den Plattencache so einfach abstellen und wenn ja wie?
3. Wie ist dann mit Raidcontrollern, also Raid in Hardware?
Gibts da ein empfehlenswertes Howto?
_________________
Gruß / Regards
tazinblack
_______________________________________________________
what's the point in being grown up if you can't be childish sometimes |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Wed Apr 08, 2009 8:31 am Post subject: |
|
|
| tazinblack wrote: | | 1. Macht es dann generell keinen Sinn ein journaling filesystem mit einem Softraid (mdadm) zu nutzen, oder muss man es dann nur "speziell" einstellen ( Ich mounte wichtige ext3 - FS mit data=journal) |
Mit Cache würde ich sagen: Nein. Zugegeben, es ist nicht da ganze Wahrheit: Mit einer gewissen Wahrscheinlichkeit wurden bei einem Crash die Daten halt doch in der richtigen Reihenfolge geschrieben. Aber der Sicherheitsgewinn ist marginal, und es kann sogar gefährlicher sein also ohne Journal. Jedenfalls wäre es mir nicht wahrscheinlich genug, um den Overhead eines Journals zu rechtfertigen.
| Quote: | | 2. Kann ich den Plattencache so einfach abstellen und wenn ja wie? |
/etc/conf.d/hdparm ("man hdparm"). Für Scsi-Platten gibt es angeblich auch so etwas (sdparm?).
| Quote: | | 3. Wie ist dann mit Raidcontrollern, also Raid in Hardware? |
Von Fake-Raids (die noch Softwareunterstützung brauchen und in undokumentiertem Format schreiben) würde ich jedenfalls abraten. Ob "richtige" Raid-Controller write-barriers beherrschen, weiß ich nicht. Beim Mounten mit "barrier=1" sagt mir ext4 zumindest im syslog bei dm-crypt-Partitionen, dass Barriers vom Device nicht unterstützt und daher abgeschaltet wurden. Wenn Du keine solche Meldung erhälst, könnte es theoretisch gehen. Garantie gibt es aber keine (ich habe sogar von Festplatten gehört, die zwar Barrier-Kommandos akzeptieren aber einfach nicht beachten...). |
|
| Back to top |
|
|
slick
Bodhisattva
Joined: 20 Apr 2003
Posts: 3495
|
| Posted: Wed Apr 08, 2009 8:42 am Post subject: |
|
|
| tazinblack wrote: | | 2. Kann ich den Plattencache so einfach abstellen und wenn ja wie? |
| Code: | | hdparm -W0 /dev/... |
| tazinblack wrote: | | 1. Macht es dann generell keinen Sinn ein journaling filesystem mit einem Softraid (mdadm) zu nutzen, oder muss man es dann nur "speziell" einstellen ( Ich mounte wichtige ext3 - FS mit data=journal) |
Diese Frage finde ich jetzt allerdings auch sehr interessant. Es kann denke ich nicht sein das einerseits Dateisysteme entwickelt werden die mit ExaByte umgehen können und angepriesen werden, aber andererseits mit (Software-)Raid oder LVM nicht klarkommen. Da läuft doch was schief, oder? Ich bezweifel doch mal das im kommerziellen Umfeld mit großen Datenmengen (jenseits einzelner Platten) auf z.B. LVM verzichtet wird. Wie macht mans da?
Was wäre denn ein passendes Dateisystem für LVM/Softwareraid? Ext2? Wie steht es da mit der Performance im Vergleich zu den Journaling FS unter gleichen Bedingungen? Die sind doch im lesen auch deutlich schneller. Das alles aufgeben?
Als Dateisystem für / (auf LVM über Softwareraid) setze ich jetzt xfs ein. Probleme sollten afaik nur die seltenen Schreibzugriffe machen, aber xfs ist beim lesen durch die Caching Mechanismen gefühlt deutlich schneller. Ist das jetzt risikoreicher als eins ohne Journal?
Last edited by slick on Wed Apr 08, 2009 8:59 am; edited 1 time in total |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6780
|
| Posted: Wed Apr 08, 2009 8:52 am Post subject: |
|
|
| slick wrote: | | Als Dateisystem für / (auf LVM über Softwareraid) setze ich jetzt xfs ein. Probleme sollten afaik nur die seltenen Schreibzugriffe machen, aber xfs ist beim lesen durch die Caching Mechanismen gefühlt deutlich schneller. Ist das jetzt risikoreicher als eins ohne Journal? |
Risiko besteht ja ohnehin immer nur beim Schreiben, und auch da nur, wenn der Computer mitten in einem Schreibprozess an ungünstiger Stelle abraucht - das ist ja i.W. der ganze Unterschied zwischen Journal und "kein Journal". Mit xfs habe ich keine Erfahrung, habe aber gehört, dass das immense Caching beim Schreiben und ein merkwürdigerweise nicht synchrones Journal zuweilen für Probleme sorgt; allzu wichtige Daten würde ich ihm daher ohne weitere Backups nicht anvertrauen, aber das gilt ja ohnehin generell. |
|
| Back to top |
|
|
tazinblack
Veteran
Joined: 23 Jan 2005
Posts: 1146
Location: Baden / Germany
|
| Posted: Thu Apr 09, 2009 10:53 am Post subject: |
|
|
| slick wrote: |
Diese Frage finde ich jetzt allerdings auch sehr interessant. Es kann denke ich nicht sein das einerseits Dateisysteme entwickelt werden die mit ExaByte umgehen können und angepriesen werden, aber andererseits mit (Software-)Raid oder LVM nicht klarkommen. Da läuft doch was schief, oder? Ich bezweifel doch mal das im kommerziellen Umfeld mit großen Datenmengen (jenseits einzelner Platten) auf z.B. LVM verzichtet wird. Wie macht mans da?
|
Also ich verwende mittlerweile im kommerziellen Umfeld für große und auch kleine Datenmengen ein Hardwareraid und als FS auf Linux EXT3 und data=journal. Mit Reiserfs bin ich schon mehrfach auf die Nase gefallen.
Auch JFS hat mich mal im Stich gelassen. (siehe https://forums.gentoo.org/viewtopic-t-751121.html
Schlechte Erfahrungen auf der Hardwareseite hab ich oft mit Systemen von Dell gemacht (PERC 4 Controller), aber auch schon ab und zu mit älteren Serveraids von IBM.
Am liebsten sind mir inzwischen externe Raidsysteme, die auch den Raidcontroller beinhalten wie sie z.B. advanced-unibyte.de verkauft. Diese werden bei mir i.d.R. per SCSI angeschlossen und können dann intern SCSI oder SATA Platten haben. Meistens hab ich die dann noch welche mit nem großen internen Cache und ner Cachepufferbatterie, damit wenn der Strom ausfällt die Daten auf dem Cache nicht verloren gehen.
Wobei das für den Privatgebrauch uninteressant ist.
Gemäß den obigen Link hab ich zum Thema XFS auch bisher öfter mal was negatives gehört.
Aber im Prinzip hast du recht, die FS können zwar inzwischen wohl exabytes verwalten, aber wie das in Zusammenarbeit mit LVM und DM (Softraid) aussieht konnte mir bisher auch noch keiner so richtig sagen.
Daher bin ich auch noch immer auf der Suche nach der sichersten Konstellation.
_________________
Gruß / Regards
tazinblack
_______________________________________________________
what's the point in being grown up if you can't be childish sometimes |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Deutsches Forum (German) 
