Kann ich ein Programm zwingen, Dateien in Blöclen zu lesen?



  • Ich möchte eine große Datei gzippen, während noch andere Operationen auf der Festplatte ausgeführt werden. Da das Thrashing verursacht, hätte ich es gerne, dass gzip die Eingangsdatei nur in größeren Blöcken liest (z.B. 10 oder 100 MB).
    Geht das mit Standardmitteln (Linux), indem ich z.B. irgendein Programm zwischenschalte?



  • Das passiert schon automatisch, weil Dateien normalerweise auf BLOCK-Devices abgelegt sind.

    Thrashing

    Was immer das auch sein mag.



  • Das nützt mir wenig, wenn selbige Blöcke 4 KB o.ä. groß sind.

    knivil schrieb:

    Was immer das auch sein mag.

    Stell dich bitte nicht dümmer, als du bist.
    Man ist das zwar von dir leider gewöhnt (sollte dir zu denken geben), aber das nützt weder dir noch sonst jemandem.



  • aqe schrieb:

    Ich möchte eine große Datei gzippen, während noch andere Operationen auf der Festplatte ausgeführt werden. Da das Thrashing verursacht, hätte ich es gerne, dass gzip die Eingangsdatei nur in größeren Blöcken liest (z.B. 10 oder 100 MB).
    Geht das mit Standardmitteln (Linux), indem ich z.B. irgendein Programm zwischenschalte?

    Deine Formulierung macht mich wundern, ob du überhaupt verstehst, was da abgeht.

    Aber generell liesse sich das Filesystem auf diesen Fall tunen, wenn du das ext4-Filesystem(?) mit "noatime,data=writeback,nobh,barrier=0,commit=300" mountest.



  • looool schrieb:

    Deine Formulierung macht mich wundern, ob du überhaupt verstehst, was da abgeht.

    Ja, k.A. was euch an meinen Formulierungen nicht passt.

    looool schrieb:

    Aber generell liesse sich das Filesystem auf diesen Fall tunen, wenn du das ext4-Filesystem(?) mit "noatime,data=writeback,nobh,barrier=0,commit=300" mountest.

    Werde ich im Hinterkopf behalten, aber diese Optionen klingen sehr danach, als würden sie nur das Schreiben optimieren. In meinem Fall möchte ich aber das gleichzeitige Lesen von Daten optimieren.



  • Naja, wenn ichs recht bedenke, lässt sich so ein Programm in weniger als fünf Minuten selbst schreiben. Wäre halt nur praktisch gewesen, wenn es etwas gegeben hätte, was auf allen Systemen schon existiert.



  • aqe schrieb:

    looool schrieb:

    Aber generell liesse sich das Filesystem auf diesen Fall tunen, wenn du das ext4-Filesystem(?) mit "noatime,data=writeback,nobh,barrier=0,commit=300" mountest.

    Werde ich im Hinterkopf behalten, aber diese Optionen klingen sehr danach, als würden sie nur das Schreiben optimieren. In meinem Fall möchte ich aber das gleichzeitige Lesen von Daten optimieren.

    Der IO-Scheduler von Linux ist schon so gut, der kann nicht dein Flaschenhals sein.



  • aqe schrieb:

    Naja, wenn ichs recht bedenke, lässt sich so ein Programm in weniger als fünf Minuten selbst schreiben. Wäre halt nur praktisch gewesen, wenn es etwas gegeben hätte, was auf allen Systemen schon existiert.

    lol, sag uns dann auch, um wie viel langsamer deine Pipe so geworden ist.



  • looool schrieb:

    aqe schrieb:

    Naja, wenn ichs recht bedenke, lässt sich so ein Programm in weniger als fünf Minuten selbst schreiben. Wäre halt nur praktisch gewesen, wenn es etwas gegeben hätte, was auf allen Systemen schon existiert.

    lol, sag uns dann auch, um wie viel langsamer deine Pipe so geworden ist.

    Alles klar. Wenn die Sache tatsächlich langsamer wird, werde ich mich nochmal melden.
    Trotzdem hat die Sache einen Vorteil: die Lärmbelästigung durch das ständige Seeken bleibt mir so größtenteils erspart.



  • aqe schrieb:

    Stell dich bitte nicht dümmer, als du bist.
    Man ist das zwar von dir leider gewöhnt (sollte dir zu denken geben), aber das nützt weder dir noch sonst jemandem.

    Spar dir sowas bitte. Ist nicht sehr hilfreich und völlig unangebracht.

    Zum Thema: Klingt tatsächlich so, als wärst du dir über einige Grundlagen nicht ganz im Klaren. Aber probier ruhig mal ein wenig herum; tut ja nicht weh.



  • looool schrieb:

    aqe schrieb:

    looool schrieb:

    Aber generell liesse sich das Filesystem auf diesen Fall tunen, wenn du das ext4-Filesystem(?) mit "noatime,data=writeback,nobh,barrier=0,commit=300" mountest.

    Werde ich im Hinterkopf behalten, aber diese Optionen klingen sehr danach, als würden sie nur das Schreiben optimieren. In meinem Fall möchte ich aber das gleichzeitige Lesen von Daten optimieren.

    Der IO-Scheduler von Linux ist schon so gut, der kann nicht dein Flaschenhals sein.

    *facepalm*



  • nman schrieb:

    Spar dir sowas bitte. Ist nicht sehr hilfreich und völlig unangebracht.

    Ja, tut mir leid. Trotzdem ist es so, dass knivils Beiträge oft nicht hilfreich sind und das liegt sicher nicht an seinem Mangel an Fachwissen, sondern nur an der Einstellung. Für mich persönlich eine Verschwendung von Kompetenz, aber natürlich kann jeder tun, was ihm beliebt.



  • Gegenfrage: Woher weisst du, dass Dateiinhalte nah beieinander auf der Platte liegen?



  • knivil schrieb:

    Gegenfrage: Woher weisst du, dass Dateiinhalte nah beieinander auf der Platte liegen?

    Natürlich kann ich das nicht garantieren, aber sofern möglich, versucht das Dateisystem ja schon, die Daten beieinander zu halten. Die großen Dateien sind weitgehend unfragmentiert und auch die Dateien der anderen Ordner scheinen nahe beieinander zu liegen (ich schließe das daraus, dass ich kaum Seekinggeräusche höre, wenn ich die Dateien nacheinander einlese). Wobei das natürlich eher für die zu gzippenden Dateien eine Rolle spielt.

    Ich habe auch ein anderes ext4-Dateisystem, das stark am Speicherlimit operiert hat und bei dem fast jede größere Datei aus tausenden Fragmenten besteht... ja, bei diesem kann ich mir sicher jeden Optimierungsversuch sparen.



  • Damit es nicht bei Mutmaßungen bleibt, habe ich mal ein kleines Tool gebastelt, das die Belegung von Dateien oder Ordnern visualisiert.

    Hier mal die Belegung des fraglichen Verzeichnisses (rot):
    http://i.imgur.com/wuMJSRR.png

    Na gut, ist jetzt etwas witzlos, weil ich es auf eine relativ frische Partition verschoben habe, aber vielleicht für andere Dinge nützlich.



  • Oder hier mein Firefoxprofil-Ordner:
    http://i.imgur.com/SaFKSDO.png

    Kein Wunder, wenn Firefox mal langsamer wird.
    Das sieht aus, als hätte eine Bombe eingeschlagen.

    Naja, genug gespammt 🙂



  • Ich hab' mir mal die ext4 optionen angesehen. inode_readahead_blks könnte nützlich sein. Da nen höheren Wert als Default (32) einstellen.
    Wobei sich das natürlich negativ (bremsend) auf andere Dinge auswirken könnte, wenn dann immer mehr Daten im Voraus gelesen werden.


Anmelden zum Antworten