Impact von hw.ata.ata_dma, FreeBSD-Bugs, Sommerwetter

h^2

hat ne Keule +1
Nachdem ich den Plan von neuer Server-Hardware erstmal auf Eis gelegt habe [1], wollte ich zumindest das FreeBSD auf eine aktuelle Version hieven, da es zunehmend schwierig wird auf dem Mix von FreeBSD-10.1 und FreeBSD-10.3 die nach außen sichtbaren Dienste aktuell zu halten. Leider sind FreeBSD12 und FreeBSD13 von der selben Regression betroffen, die es mir unmöglich machte damals auf FreeBSD-10.3 zu aktualisieren [2].
Dass da in 4 Jahren kein einziger Response drauf kam stimmt schon etwas deprimierend... naja.

Ich habe jetzt ein bisschen rumprobiert und das Setzen von
Code:
hw.ata.ata_dma=0
in der loader.conf ermöglicht es das System zu booten mit neueren FreeBSD-Versionen. Diese Flag sieht aber so aus, als hätte sie einen nachhaltig negativen Effekt auf die Performance der Platten was bei einem Fileserver eher ungünstig ist.

Wisst ihr genaueres bzgl. des Einflusses dieser Flag? Kann ich die irgendwie während dem Boot ausschalten und später wieder an? Kann ich das selektiv für die SSD machen, bzw. ergibt das überhaupt Sinn? [Die soll das System ja schneller machen]

Bin für jede Hilfe dankbar!


[1] https://www.bsdforen.de/threads/mainboard-für-kleines-aber-schnelles-nas.35728/
[2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210132
 
Wenn ich das richtig sehe wird dma (=direct memory access) ausgeschaltet. Ob das einen so schweren Einfluss auf die Performance hat, weiss ich nicht. Probier es doch einfach mal aus mit ein paar performance tools. Was für eine Hardware steht denn genau dahiner?
VG Norbert :) :)
 
Interessant ist auch die Frage, warum er bei dir komplett blockiert. Mein PC Engines APU1 fährt auch mit gesperrtem SED hoch. Ich habe dann ein einfaches Script zum Entsperren und mounten. Wie wäre als Workaround grob sowas:
  1. Nach dem Kaltstart mit hw.ata.ata_dma=0 booten.
  2. Das SED entsperren, locken und rebooten. Der Reboot sollte es nicht wieder sperren, da der Strom nicht getrennt wird.
  3. Normal booten.
 
Ich steck da nicht allzu tief drin, aber
ata ist doch der alte Parallelstandard. Aktuelle SATA Platten sollten über ahci laufen. Wenn FreeBSD den ata controller nicht kennt und als FallBack vom dümmst möglichen ausgeht schaltet es evtl in den PIO mode. Korrigiert mich, wenn ich da was durcheinandergebracht habe.
 
Interessant ist auch die Frage, warum er bei dir komplett blockiert.
Ja, deswegen hatte ich ja das Issue erstellt, auf das nie jemand reagierte ;'(
Mein PC Engines APU1 fährt auch mit gesperrtem SED hoch. Ich habe dann ein einfaches Script zum Entsperren und mounten.
Ja, das ist ja auch der Setup, den ich bis FreeBSD-10.1 benutze.

Wie wäre als Workaround grob sowas:
Das ist tatsächlich eine Idee. Ich muss nur sicherstellen, dass er auf jeden Fall per default ohne ata_dma bootet, denn sonst lässt sich das System nicht mehr remote starten. Werde wahrscheinlich per rc.local sicherstellen dass hw.ata.ata_dma=0 gesetzt ist und nur nachdem entsperren einmal manuell ohne booten.

Ich steck da nicht allzu tief drin, aber ata ist doch der alte Parallelstandard. Aktuelle SATA Platten sollten über ahci laufen.

Ich kann mir aber gut vorstellen dass bestimmte Treiberschichten von dem einen für das andere verwendet werden... Außerdem ist das Board ziemlich alt... Aber ich checke auch nochmal ob ich da vielleicht im BIOS noch was umstellen kann.
 
Ob das einen so schweren Einfluss auf die Performance hat, weiss ich nicht. Probier es doch einfach mal aus mit ein paar performance tools.

Also laut diskinfo -v -c -t halbiert es die Transfer Rates der SSD. Die Performance der HDDs ist hingegen kaum betroffen.
 
Das ist tatsächlich eine Idee. Ich muss nur sicherstellen, dass er auf jeden Fall per default ohne ata_dma bootet, denn sonst lässt sich das System nicht mehr remote starten. Werde wahrscheinlich per rc.local sicherstellen dass hw.ata.ata_dma=0 gesetzt ist und nur nachdem entsperren einmal manuell ohne booten.

So, dass klappt so weit. Nur zur Info für die Nachwelt.
 
Zurück
Oben