Kann ich mein Linux-System für aggressiveres Dateisystem-Caching konfigurieren?


119

Ich mache mir weder Gedanken über die RAM-Auslastung (da ich genug habe) noch über Datenverluste im Falle eines versehentlichen Herunterfahrens (da meine Stromversorgung gesichert ist, ist das System zuverlässig und die Daten sind nicht kritisch). Aber ich verarbeite viele Dateien und könnte eine Leistungssteigerung gebrauchen.

Aus diesem Grund möchte ich das System so einrichten, dass mehr RAM für das Lese- und Schreib-Caching des Dateisystems verwendet wird, um Dateien vorab aggressiv abzurufen (z. B. die gesamte Datei, auf die eine Anwendung zugreift, vorauslesen, falls die Datei eine vernünftige Größe hat oder zumindest Lesen Sie einen großen Teil davon vor (andernfalls) und leeren Sie die Schreibpuffer weniger häufig. Wie kann das erreicht werden?

Ich verwende ext3- und ntfs-Dateisysteme (ich verwende viel ntfs!) Mit XUbuntu 11.10 x86.


6
Wenn Sie über viel RAM verfügen, sich viel um die Leistung und keinen Datenverlust kümmern, kopieren Sie einfach alle Ihre Daten auf eine RAM-Disk und stellen Sie sie von dort aus bereit. Alle Aktualisierungen werden beim Absturz / Herunterfahren verworfen. Wenn dies bei Ihnen nicht funktioniert, müssen Sie möglicherweise "genug" für den Arbeitsspeicher angeben oder angeben, wie kritisch die Daten nicht sind.
James Youngman

1
@Nils, der Computer ist ein Laptop, also glaube ich, der Controller ist ziemlich gewöhnlich.
Ivan

1
Eine Möglichkeit, die Leistung erheblich zu verbessern, besteht darin, die Haltbarkeit von Daten zu überspringen. Deaktivieren Sie einfach die Synchronisierung auf der Festplatte, auch wenn einige Apps eine Synchronisierung anfordern. Dies führt zu Datenverlust, falls Ihr Speichergerät jemals unter Stromausfall leidet. Wenn Sie es trotzdem tun möchten, führen Sie es einfach aus sudo mount -o ro,nobarrier /path/to/mountpointoder passen Sie es /etc/fstaban, um es nobarrierfür jedes Dateisystem einzuschließen, das Sie für eine verbesserte Leistung opfern möchten . Wenn Ihr Speichergerät jedoch über einen internen Akku wie die Intel 320 SSD-Serie verfügt, nobarrierverursacht die Verwendung keinen Datenverlust.
Mikko Rantalainen

1
Die Verwendung von Nobarrier wird in Red Hat Enterprise Linux 6 nicht mehr empfohlen, da die negativen Auswirkungen von Schreibbarrieren auf die Leistung vernachlässigbar sind (ca. 3%). Die Vorteile von Schreibbarrieren überwiegen normalerweise gegenüber den Leistungsvorteilen beim Deaktivieren. Darüber hinaus sollte die Nobarrier-Option niemals für Speicher verwendet werden, der auf virtuellen Maschinen konfiguriert ist. access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/…
Ivailo Bardarov

1
Zwei Punkte - 1) Es gibt Linux-Distributionen, die auf Debian oder Ubuntu basieren, wie Puppy Linux und AntiX Linux, und viele andere, die das gesamte Betriebssystem in geschichteten Ramdisk-Partitionen (dh AUFS oder Overlayfs) unterbringen und transparent verwalten. Sehr schnell! - 2) In der Praxis haben wir festgestellt, dass ein sehr großes System, das mehr Cache benötigt, die LEISTUNG VERRINGERN kann. Mit zunehmender Speichergeschwindigkeit (dh SSD) verringert sich die optimale benötigte Cache-Größe. Es ist jedoch nicht möglich, diese Größe zu ermitteln, ohne mit Ihrem speziellen System zu experimentieren. Wenn die Erhöhung nicht funktioniert, versuchen Sie sie zu verringern.
DocSalvager

Antworten:


107

Die Verbesserung der Disk - Cache Performance im Allgemeinen ist mehr als nur die Dateisystem - Cache - Größe zu erhöhen , wenn Ihr gesamtes System in RAM paßt , in dem Fall , dass Sie RAM - Laufwerk verwendet werden sollen ( tmpfsist gut , weil es erlaubt , zurück auf der Platte fallen , wenn Sie die RAM in einigen Fällen müssen) für die Laufzeitspeicherung (und möglicherweise ein initrd-Skript, um das System beim Start vom Speicher auf das RAM-Laufwerk zu kopieren).

Sie haben nicht festgestellt, ob es sich bei Ihrem Speichergerät um eine SSD oder eine Festplatte handelt. Hier ist, was ich gefunden habe, um für mich zu arbeiten (in meinem Fall sdaist ein HDD angebracht an /homeund sdbist SSD angebracht an /).

Optimieren Sie zuerst den Teil zum Laden des Materials vom Speicher zum Cache:

Hier ist mein Setup für die Festplatte (stellen Sie sicher, dass AHCI + NCQ im BIOS aktiviert ist, wenn Sie umschalten):

echo cfq > /sys/block/sda/queue/scheduler
echo 10000 > /sys/block/sda/queue/iosched/fifo_expire_async
echo 250 > /sys/block/sda/queue/iosched/fifo_expire_sync
echo 80 > /sys/block/sda/queue/iosched/slice_async
echo 1 > /sys/block/sda/queue/iosched/low_latency
echo 6 > /sys/block/sda/queue/iosched/quantum
echo 5 > /sys/block/sda/queue/iosched/slice_async_rq
echo 3 > /sys/block/sda/queue/iosched/slice_idle
echo 100 > /sys/block/sda/queue/iosched/slice_sync
hdparm -q -M 254 /dev/sda

Beachten Sie, dass das Festplattengehäuse hoch fifo_expire_async(normalerweise schreibend) und lang ist slice_sync, damit ein einzelner Prozess einen hohen Durchsatz erzielt (auf slice_synceine niedrigere Anzahl eingestellt, wenn mehrere Prozesse gleichzeitig auf Daten von der Festplatte warten). Das slice_idleist immer ein Kompromiss für HDDs , aber es irgendwo in Reichweite Einstellung 3-20 sollte je nach Festplattennutzung und Disk - Firmware in Ordnung sein. Ich bevorzuge es, auf niedrige Werte zu zielen, aber eine zu niedrige Einstellung zerstört Ihren Durchsatz. Die quantumEinstellung scheint den Durchsatz stark zu beeinflussen, aber versuchen Sie, dies so gering wie möglich zu halten, um die Latenz auf einem vernünftigen Niveau zu halten. Eine quantumzu niedrige Einstellung zerstört den Durchsatz. Werte im Bereich von 3 bis 8 scheinen mit Festplatten gut zu funktionieren. Die ungünstigste Wartezeit für einen Lesevorgang ist ( quantum* slice_sync) + ( slice_async_rq*slice_async) ms wenn ich das kernelverhalten richtig verstanden habe. Der asynchrone Modus wird hauptsächlich für Schreibvorgänge verwendet. Da Sie bereit sind, das Schreiben auf die Festplatte zu verzögern, sollten Sie beide slice_async_rqund slice_asyncsehr niedrige Werte festlegen . Wenn Sie jedoch einen slice_async_rqzu niedrigen Wert einstellen , werden die Lesevorgänge möglicherweise unterbrochen, da die Schreibvorgänge nach den Lesevorgängen nicht mehr verzögert werden können. Meine Config wird versuchen , nach 10 Sekunden auf den meisten Daten auf der Festplatte zu schreiben , nachdem die Daten übergeben wurde auf Kernel aber da Sie Datenverlust bei Stromausfall tolerieren können auch eingestellt , fifo_expire_asyncum 3600000zu sagen , dass 1 Stunde für die Verzögerung auf der Festplatte in Ordnung ist. Halten Sie den slice_asyncWert jedoch niedrig, da ansonsten eine hohe Leselatenz auftreten kann.

Der hdparmBefehl ist erforderlich, um zu verhindern, dass AAM einen Großteil der von AHCI + NCQ zugelassenen Leistung beeinträchtigt. Wenn Ihre Festplatte zu laut ist, überspringen Sie diese.

Hier ist mein Setup für SSD (Intel 320 Serie):

echo cfq > /sys/block/sdb/queue/scheduler
echo 1 > /sys/block/sdb/queue/iosched/back_seek_penalty
echo 10000 > /sys/block/sdb/queue/iosched/fifo_expire_async
echo 20 > /sys/block/sdb/queue/iosched/fifo_expire_sync
echo 1 > /sys/block/sdb/queue/iosched/low_latency
echo 6 > /sys/block/sdb/queue/iosched/quantum
echo 2 > /sys/block/sdb/queue/iosched/slice_async
echo 10 > /sys/block/sdb/queue/iosched/slice_async_rq
echo 1 > /sys/block/sdb/queue/iosched/slice_idle
echo 20 > /sys/block/sdb/queue/iosched/slice_sync

Hier sind die niedrigen Werte für verschiedene Slice-Einstellungen zu beachten. Die wichtigste Einstellung für eine SSD ist slice_idledie Einstellung 0-1. Das Setzen auf Null verschiebt alle Sortierentscheidungen zu nativem NCQ, während das Setzen auf 1 es dem Kernel ermöglicht, Anforderungen zu sortieren (aber wenn der NCQ aktiv ist, kann die Hardware die Sortierung des Kernels teilweise außer Kraft setzen). Testen Sie beide Werte, um festzustellen, ob Sie den Unterschied erkennen können. Für 320 Serie Intel scheint es , dass Einstellung slide_idlezu 0den besten Durchsatz gibt aber Einstellung es 1gibt am besten (niedrigsten) Gesamtlatenz.

Weitere Informationen zu diesen Tunables finden Sie unter http://www.linux-mag.com/id/7572/ .

Nachdem wir den Kernel so konfiguriert haben, dass Daten mit vernünftiger Leistung von der Festplatte in den Cache geladen werden, ist es an der Zeit, das Cache-Verhalten anzupassen:

Gemäß den Benchmarks, die ich durchgeführt habe, würde ich mir überhaupt nicht die Mühe machen, vorausgelesene Daten zu setzen blockdev. Die Standardeinstellungen des Kernels sind in Ordnung.

Stellen Sie das System so ein, dass das Auslagern von Dateidaten dem Anwendungscode vorgezogen wird (dies spielt keine Rolle, wenn Sie über genügend RAM verfügen, um das gesamte Dateisystem und den gesamten Anwendungscode sowie den gesamten von den Anwendungen im RAM zugewiesenen virtuellen Speicher zu behalten ). Dadurch wird die Wartezeit für den Austausch zwischen verschiedenen Anwendungen über die Wartezeit für den Zugriff auf große Dateien von einer einzelnen Anwendung aus verringert:

echo 15 > /proc/sys/vm/swappiness

Wenn Sie es vorziehen, Anwendungen fast immer im RAM zu behalten, können Sie dies auf 1 setzen. Wenn Sie dies auf Null setzen, wird der Kernel überhaupt nicht ausgetauscht, es sei denn, dies ist unbedingt erforderlich, um OOM zu vermeiden. Wenn der Arbeitsspeicher begrenzt ist und Sie mit großen Dateien arbeiten (z. B. HD-Videobearbeitung), ist es möglicherweise sinnvoll, diesen Wert auf nahezu 100 festzulegen.

Heutzutage (2017) bevorzuge ich es, überhaupt keinen Swap zu haben, wenn du genug RAM hast. Wenn Sie keinen Swap haben, verlieren Sie normalerweise 200-1000 MB RAM auf einem lang laufenden Desktop-Computer. Ich bin bereit, so viel zu opfern, um Wartezeiten im schlimmsten Fall zu vermeiden (Austausch von Anwendungscode, wenn der RAM voll ist). In der Praxis bedeutet dies, dass ich OOM Killer dem Tauschen vorziehe. Wenn Sie das Austauschen zulassen / benötigen, möchten Sie möglicherweise auch die Anzahl erhöhen /proc/sys/vm/watermark_scale_factor, um eine gewisse Latenz zu vermeiden. Ich würde Werte zwischen 100 und 500 vorschlagen. Sie können diese Einstellung als Handelswert für die CPU-Auslastung betrachten, um die Swap-Latenz zu verringern. Der Standardwert ist 10 und der maximal mögliche Wert 1000. Ein höherer Wert sollte (gemäß der Kerneldokumentation ) zu einer höheren CPU-Auslastung für kswapdProzesse und einer geringeren Gesamtwartezeit für das Austauschen führen.

Als nächstes teilen Sie dem Kernel mit, dass er die Verzeichnishierarchie lieber im Speicher als im Dateiinhalt belassen soll, falls RAM freigegeben werden muss.

echo 10 > /proc/sys/vm/vfs_cache_pressure

Rahmen vfs_cache_pressureEin zu niedriger Wert ist sinnvoll, da der Kernel in den meisten Fällen die Verzeichnisstruktur kennen muss, bevor er Dateiinhalte aus dem Cache verwenden kann. Wenn der Verzeichnis-Cache zu früh geleert wird, wird der Datei-Cache nahezu wertlos. Ziehen Sie in Betracht, mit dieser Einstellung auf 1 zu gehen, wenn Sie viele kleine Dateien haben (mein System verfügt über etwa 150.000 Fotos mit 10 Megapixeln und zählt als System mit vielen kleinen Dateien). Setzen Sie es niemals auf Null, oder die Verzeichnisstruktur bleibt immer im Speicher, auch wenn das System nicht genügend Speicher hat. Dies auf einen hohen Wert zu setzen ist nur dann sinnvoll, wenn Sie nur wenige große Dateien haben, die ständig neu gelesen werden (auch hier wäre HD-Videobearbeitung ohne genügend RAM ein Beispiel). Die offizielle Kernel-Dokumentation besagt, dass "

Ausnahme: Wenn Sie eine wirklich große Menge an Dateien und Verzeichnissen haben und selten alle Dateien berühren / lesen / auflisten, die vfs_cache_pressurehöher als 100 sind, kann dies sinnvoll sein. Dies gilt nur, wenn Sie nicht über genügend RAM verfügen und nicht die gesamte Verzeichnisstruktur im RAM behalten können und dennoch über genügend RAM für den normalen Dateicache und die normalen Prozesse verfügen (z. B. firmenweiter Dateiserver mit vielen Archivinhalten). Wenn Sie der Meinung sind, dass Sie auf vfs_cache_pressureüber 100 ansteigen müssen, verfügen Sie nicht über genügend RAM. Erhöhen vfs_cache_pressurekann helfen, aber die einzige echte Lösung ist, mehr RAM zu bekommen. Wenn Sie vfs_cache_pressureeine hohe Anzahl von Opfern eingestellt haben, bedeutet dies, dass die durchschnittliche Leistung insgesamt stabiler ist.

Schließlich weisen Sie den Kernel an, bis zu 99% des Arbeitsspeichers als Cache für Schreibvorgänge zu verwenden, und weisen Sie den Kernel an, bis zu 50% des Arbeitsspeichers zu verwenden, bevor der zu schreibende Prozess verlangsamt wird (Standard für dirty_background_ratioist 10). Warnung: Ich persönlich würde dies nicht tun, aber Sie haben behauptet, über genügend RAM zu verfügen und sind bereit, die Daten zu verlieren.

echo 99 > /proc/sys/vm/dirty_ratio
echo 50 > /proc/sys/vm/dirty_background_ratio

Und sagen Sie, dass eine Schreibverzögerung von 1 Stunde in Ordnung ist, um überhaupt mit dem Schreiben von Dingen auf die Festplatte zu beginnen (wieder würde ich dies nicht tun):

echo 360000 > /proc/sys/vm/dirty_expire_centisecs
echo 360000 > /proc/sys/vm/dirty_writeback_centisecs

Wenn Sie all diese /etc/rc.localElemente an das Ende setzen und "following" einfügen, wird alles so schnell wie möglich nach dem Booten im Cache gespeichert (tun Sie dies nur, wenn Ihr Dateisystem wirklich in den Arbeitsspeicher passt):

(nice find / -type f -and -not -path '/sys/*' -and -not -path '/proc/*' -print0 2>/dev/null | nice ionice -c 3 wc -l --files0-from - > /dev/null)&

Oder eine etwas einfachere Alternative, die möglicherweise besser funktioniert (nur Cache /homeund dies /usrnur tun, wenn Sie /homeund /usrwirklich in RAM passen):

(nice find /home /usr -type f -print0 | nice ionice -c 3 wc -l --files0-from - > /dev/null)&

3
Eine gut informierte und insgesamt viel bessere Antwort als die akzeptierte! Dieser ist unterschätzt ... Ich denke, die meisten Leute wollen nur einfache Anweisungen, ohne sich die Mühe zu machen, zu verstehen, was sie wirklich tun ...
Vladimir Panteleev

2
@Phpdevpad: Außerdem lautete die Frage "Ich mache mir keine Sorgen um die RAM-Auslastung [...]" - ich glaube nicht, dass ein Maemo-Gerät dafür geeignet ist.
Mikko Rantalainen

1
Ist noop oder deadline nicht ein besserer Scheduler für SSDs?
rep_movsd

1
@rep_movsd Ich habe nur Intel-SSD-Laufwerke verwendet, aber diese Laufwerke sind immer noch langsam genug, um mit intelligenteren Schedulern wie CFQ eine bessere Gesamtleistung zu erzielen. Wenn Ihr SSD-Laufwerk mehr als 100.000 zufällige IOPS verarbeiten kann, ist die Verwendung von noop oder deadline auch bei schneller CPU sinnvoll. Mit "schneller CPU" meine ich etwas, bei dem mindestens mehrere 3GHz-Kerne nur für E / A verfügbar sind.
Mikko Rantalainen

1
Weitere Informationen zu diesen VM-Tunables finden Sie in den VM-Kernel-Dokumenten .
Joeytwiddle

16

Erstens empfehle ich NICHT, weiterhin NTFS zu verwenden, da die Implementierung von ntfs unter Linux jederzeit zu Leistungs- und Sicherheitsproblemen führen kann.

Sie können verschiedene Dinge tun:

  • benutze einige neuere fs wie ext4oderbtrfs
  • Versuchen Sie beispielsweise, Ihren io-Scheduler zu ändern bfq
  • Swap ausschalten
  • benutze einen automatischen Preloader wie preload
  • Verwenden Sie so etwas wie systemddas Vorladen beim Booten
  • ... und noch etwas mehr

Vielleicht möchten Sie es versuchen :-)


1
Ich bin bereits einmal von NTFS zu ext4 gewechselt und habe als einzige NTFS-Partition die Windows-Systempartition gelassen. Es stellte sich jedoch für mich als problematisch heraus und ich habe mich wieder an NTFS als Hauptdatenpartition gewandt (in der ich alle meine Dokumente, Downloads, Projekte, Quellcode usw. speichere). Ich gebe nicht auf, meine Partitionsstruktur und meinen Workflow zu überdenken (um weniger Windows zu verwenden), aber im Moment scheint es keine realistische Option zu sein, auf NTFS zu verzichten.
Ivan

Wenn Sie Ihre Daten auch in Windows verwenden müssen, ist NTFS möglicherweise die einzige Option. (viele andere Optionen zur Verfügung, wenn Sie Ihr Windows nur als VM in Linux verwenden können)
Felix Yan

1
Eine Zusammenfassung der vermeintlichen Probleme von NTFS wäre hilfreich gewesen.
Underscore_d

2
NTFS unter Linux ist mit Ausnahme der Leistung ziemlich akzeptabel. Angesichts der Tatsache, dass es speziell um die Verbesserung der Dateisystemleistung ging, sollte NTFS als Erstes eingesetzt werden.
Mikko Rantalainen

Obwohl btrfses sich um ein kürzlich entwickeltes Dateisystem handelt, würde ich dies vermeiden, wenn Leistung benötigt wird. Wir haben ansonsten identische Systeme mit btrfsund ext4Dateisystemen ausgeführt und ext4gewinnen in der realen Welt mit großem Spielraum ( btrfsscheint etwa 4-fache CPU-Zeit zu erfordern, die ext4für dasselbe Leistungsniveau erforderlich ist und mehr Festplattenoperationen für einen einzigen logischen Befehl verursacht). Je nach Arbeitsbelastung würde ich vorschlagen ext4, jfsoder xfsfür jede Leistung anspruchsvolle Arbeit.
Mikko Rantalainen

8

Lesen Sie weiter:

Auf 32-Bit-Systemen:

blockdev --setra 8388607 /dev/sda

Auf 64-Bit-Systemen:

blockdev --setra 4294967295 /dev/sda

Hinter den Cache schreiben:

echo 100 > /proc/sys/vm/dirty_ratio

Dadurch wird bis zu 100% Ihres freien Speichers als Schreibcache verwendet.

Oder Sie können alles daran setzen und tmpfs verwenden. Dies ist nur relevant, wenn Sie über genügend RAM verfügen. Setzen Sie dies in /etc/fstab. Ersetzen Sie 100 G durch die Größe des physischen RAM.

tmpfs /mnt/tmpfs tmpfs size=100G,rw,nosuid,nodev 0 0

Dann:

mkdir /mnt/tmpfs; mount -a

Verwenden Sie dann / mnt / tmpfs.


5
3 GB oder 2 TB Readahead? Ja wirklich? Wissen Sie überhaupt, was diese Optionen bewirken?
Cobra_Fast

1
@Cobra_Fast Weißt du was es bedeutet? Ich habe wirklich keine Ahnung und bin jetzt interessiert.
Syss

3
@syss Die Readahead-Einstellungen werden als Anzahl der "Speicherblöcke" gespeichert, nicht als Byte oder Bit. Die Größe eines Blocks wird zum Zeitpunkt der Kernel-Kompilierung (da Readahead-Blöcke Speicherblöcke sind) oder zum Zeitpunkt der Dateisystemerstellung in einigen Fällen festgelegt. Normalerweise enthält ein Block 512 oder 4096 Bytes. Siehe linux.die.net/man/8/blockdev
Cobra_Fast

6

Sie können die Vorauslesegröße mit festlegen blockdev --setra sectors /dev/sda1, wobei Sektoren die gewünschte Größe in 512-Byte-Sektoren ist.


2

Meine Killereinstellung ist sehr einfach und sehr effektiv:

echo "2000" > /proc/sys/vm/vfs_cache_pressure

Die Erklärung aus der Kerneldokumentation :

vfs_cache_pressure

Steuert die Tendenz des Kernels, den zum Zwischenspeichern von Verzeichnis- und Inode-Objekten verwendeten Speicher zurückzugewinnen.

Bei dem Standardwert von vfs_cache_pressure = 100 versucht der Kernel, Einträge und Inodes mit einer "fairen" Rate in Bezug auf die Pagecache- und Swapcache-Rückforderung zurückzugewinnen. Wenn Sie vfs_cache_pressure verringern, zieht der Kernel es vor, Dentry- und Inode-Caches beizubehalten. Wenn vfs_cache_pressure = 0 ist, fordert der Kernel aufgrund des Speicherdrucks niemals Einträge und Inodes zurück. Dies kann leicht zu Speicherproblemen führen. Wenn Sie vfs_cache_pressure auf über 100 erhöhen, fordert der Kernel bevorzugt Einträge und Inodes zurück.

vfs_cache_pressure Bei 2000 wird der Großteil des Computing im RAM ausgeführt und sehr spät geschrieben.


4
Wenn Sie vfs_cache_pressurezu hoch 2000einstellen (was ich für zu hoch halte ), wird der Festplattenzugriff selbst für einfache Dinge wie Verzeichnislisten, die leicht in den Cache passen sollten, unnötig. Wie viel RAM haben Sie und was machen Sie mit dem System? Wie ich in meiner Antwort schrieb, ist die Verwendung eines hohen Werts für diese Einstellung beispielsweise für die HD-Videobearbeitung mit begrenztem RAM sinnvoll.
Mikko Rantalainen

2
Beachten Sie, dass die Dokumentation, auf die verwiesen wird, fortgesetzt wird: "Das Erhöhen von vfs_cache_pressure deutlich über 100 hinaus kann sich negativ auf die Leistung auswirken. Für die Rückforderung von Code sind verschiedene Sperren erforderlich, um freischaltbare Verzeichnis- und Inode-Objekte zu finden. Mit vfs_cache_pressure = 1000 wird nach zehnmal mehr freischaltbaren Objekten gesucht als dort sind."
Mikko Rantalainen

1

Nicht im Zusammenhang mit Schreibcaching, sondern mit Schreibvorgängen:

  • Für ein ext4-System können Sie das Journaling vollständig deaktivieren

    Dadurch wird die Anzahl der Schreibvorgänge auf der Festplatte für ein bestimmtes Update verringert, das Dateisystem befindet sich jedoch möglicherweise nach einem unerwarteten Herunterfahren in einem inkonsistenten Zustand.

So verhindern Sie, dass Festplattenlesevorgänge Schreibvorgänge auslösen:

  • Mount mit der Option relatime oder noatime

    Wenn Sie eine Datei lesen, werden normalerweise die Metadaten zum Zeitpunkt des letzten Zugriffs für diese Datei aktualisiert. Die noatimeOption deaktiviert dieses Verhalten. Dadurch werden unnötige Schreibvorgänge auf der Festplatte reduziert, die Metadaten sind jedoch nicht mehr verfügbar. Einige Distributionen (z. B. Manjaro) haben dies als Standard für alle Partitionen übernommen (wahrscheinlich, um die Lebensdauer früherer SSD-Modelle zu erhöhen).

    relatimeAktualisiert die Zugriffszeit seltener, je nach Heuristik, die zur Unterstützung von Anwendungen beiträgt, die atime verwenden. Dies ist die Standardeinstellung unter Red Hat Enterprise Linux.

Andere Optionen:

  • In den obigen Kommentaren teilte Mikko die Möglichkeit der Montage mit der Nobarrier- Option. Aber Ivailo zitierte RedHat, der davor warnte . Wie sehr möchten Sie diese zusätzlichen 3%?
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.