Für mich war es eine Herausforderung, herauszufinden, was die beste Wahl für den I/O-Scheduler im Kernel ist. Zuerst habe ich gelernt, dass es subjektiv ist und dann vom verwendeten Dateisystem abhängt.
Ich weiß, dass Sie No-opauf jeden Fall Solid-State-Laufwerke (SSDs) verwenden sollten.
Ich möchte wissen, was die beste Wahl für normale (rotierende) Festplatten mit Ext4- und NTFS-Dateisystemen (MBR-Stil) ist.
Und hat GPT oder MBR irgendeinen Einfluss auf meine Wahl?
Antwort1
Ich weiß, dass Sie für Solid-State-Laufwerke oder SSDs auf jeden Fall No-op verwenden sollten.
Nicht unbedingt. Ich weiß nicht, warum die Leute SSDs immer noch als eine Art Sonderfall behandeln, bei dem man die Vorteile anderer Scheduler nicht braucht. Bei rotierenden Festplatten ist es nur wichtiger, Anfragen zusammenzuführen. Das Zusammenführen von Anfragen ist nur eine Sache, die der Scheduler macht.
CFQ, Deadline usw. können noch mehr. CFQ ermöglicht es Ihnen beispielsweise, bestimmten Prozessen Vorrang vor anderen zu geben (über ionice), während Deadline Ihnen Latenzgarantien gibt. Beides kann für SSDs weiterhin relevant sein.
Wenn Sie auf rotierende Datenträger verzichten, wird sich Ihre Entscheidung bezüglich der Planung wahrscheinlich eher darauf beziehen, wie Sie die Bandbreite zur und von der Festplatte aufteilen möchten, und nicht nur darauf, Anfragen zusammenzuführen.
BEARBEITEN:Ich möchte auch darauf hinweisen, dass Zusammenführungen auf meinem System (unabhängig vom Scheduler) mithilfe des /sys/block/sdXX/queue/nomergesTunables deaktiviert werden können. Deadline bietet auch ein Tunable zum Deaktivieren von Front-Merges.
Ich möchte wissen, was die beste Wahl für eine normale (rotierende) Festplatte mit ext4- und NTFS-Dateisystemen ist (MBR-Stil).
Die Wahl des Schedulers hängt wahrscheinlich nicht besonders vom verwendeten Dateisystem ab. Dentries und häufig verwendete Dateien landen sowieso im Dateisystem-Cache. Wie dem auch sei, keiner der Scheduler scheint über Funktionen zu verfügen, die einem Dateisystem (XFS, ext3, ext4+extents, Reiserfs usw.) gegenüber einem anderen Vorteile verschaffen würden.
NTFS neigt zu starker Fragmentierung, daher read_ahead_kbist eine kleinere Version wahrscheinlich von Vorteil (Sie müssen damit herumspielen, um zu sehen, was für Sie funktioniert). Wenn es sich im Grunde genommen um ein stark fragmentiertes Volume handelt, wird das Einbeziehen der benachbarten Daten wahrscheinlich nur die Bandbreite drosseln, die für eine legitime Anfrage hätte verwendet werden können.
Und GPT/MBR haben auf diese Entscheidung überhaupt keinen Einfluss.