ubuntuusers.de

Hallo zusammen,

Ideen und Fragen gehen mir nicht aus.

Was ich mir schon immer gwünscht hätte: eine Warteschlange für Laufwerksoperationen, so wie es auch die Druckerwarteschlange für Druckjobs schon ganz lange ganz selbstverständlich gibt.

Problem: ich kopiere 1 GB von Laufwerk 1 auf 2. Dauert etwas, weil relevante Datenmenge, geht aber zügig, alles gut. Dann fällt mir aber ein, ich müsste auch noch 2 GB von Laufwerk 3 nach 1 kopieren. Ergebnis: bei beiden Kopiervorgängen bricht die Performance ein, weil die Hardware versucht beide Jobs im Zeitscheibenverfahren quasiparallel abzuwickeln und sich dann tot-zeitscheibt. Overhead übertrifft die Summe der Zeit der beiden Einzelvorgänge bei weitem.

Was man also bräuchte wäre eine Warteschlange für längere Disk-Operationen. Ein System, das abschätzt wie lange ein Vorgang dauern würde (easy: Datenmenge/Performance) und wenn ein Vorgang mehr als sagen wir 1 sec dauern wird und auf diesem Laufwerk bereits ein anderer solcher Vorgang aktiv ist, der zweite Vorgang erst gestartet wird, wenn der erste fertig ist.

Gibts sowas schon und wenn nein warum nicht 😉

Grüße -incredion

Nicht ganz das was Du suchst, aber der Krusader hat in der neuesten Version endlich die von seinem Vorbild Total Commander (Windows) bekannte Kopierwarteschlange (im Kopieren-Dialog F2 drücken).

V for Vortex schrieb:

Nicht ganz das was Du suchst, aber der Krusader hat in der neuesten Version endlich die von seinem Vorbild Total Commander (Windows) bekannte Kopierwarteschlange (im Kopieren-Dialog F2 drücken).

vielleicht könnte man so etwas ja in Dolphin integrieren - und dann in nautilus und dann in... oder, was ich persönlich genau deswegen vorziehen würde: direkt in den dateisystemtreiber im kernel. es geht ja um ganz elementares management zur optimierung von dateisystemzugriffen und das macht man am besten an zentraler stelle.

gruß -incredion

@incredion: In den Dateisystemtreiber kann man das nicht einbauen. Der hat ja keine Ahnung warum eine Datei geöffnet wird, und kann auch nicht "hellsehen" was als nächstes gelesen oder geschrieben wird. Eine Aktion wie "kopieren" gibt es auf dieser Ebene nicht.

Marc 'BlackJack' Rintsch schrieb:

@incredion: In den Dateisystemtreiber kann man das nicht einbauen. Der hat ja keine Ahnung warum eine Datei geöffnet wird, und kann auch nicht "hellsehen" was als nächstes gelesen oder geschrieben wird. Eine Aktion wie "kopieren" gibt es auf dieser Ebene nicht.

ok, wieder was gelernt. aber ich denke die botschaft ist klar. die niedrigste ebene, der die einzelnen copyjobs hingeschoben werden ist diejenige welche. sonst wird das in jedem dateimanager extra gelöst und das rad dabei ein halbes dutzend mal neu erfunden.

@incredion: Die niedrigste Ebene scheint aber der jeweilige Dateimanager zu sein, denn der erledigt in der Regel das komplette Kopieren selbst, also Quelldatei öffnen, Zieldatei öffnen, häppchenweise von einer lesen und in die andere schreiben, und dabei den Fortschritt darstellen.

Marc 'BlackJack' Rintsch schrieb:

@incredion: Die niedrigste Ebene scheint aber der jeweilige Dateimanager zu sein, denn der erledigt in der Regel das komplette Kopieren selbst, also Quelldatei öffnen, Zieldatei öffnen, häppchenweise von einer lesen und in die andere schreiben, und dabei den Fortschritt darstellen.

ok, wenn du das sagst. mir schwebt halt immer das bild der druckerwarteschlange vor. ist im grunde dieselbe sache. aufgaben, die etwas dauern können in die warteschlange geschoben werden und werden dort mit einer reihenfolge, die auch prioritäten (wichtiger und schneller und kann warten) enthalten kann der reihe nach abgewickelt. ein job nach dem anderen, ohne durcheinander.

wundert mich ein bisschen dass gerade das nicht nur multitasking- sondern auch noch multiuser-system unix sowas gar nicht hat. wenn da alle user gleichzeitig auf den massenspeicher zugreifen geht doch gar nichts mehr, weil die festplatte nur noch mit zeitscheibenverteiltem hin- und herfahren des lesekopfes beschäftigt ist, statt eine datei in einem burst komplett hintereinander weg zu schreiben und dann die nächste. alternativ (lesekopf bleibt an ort und stelle) bekommt man die fragmentiertesten dateien, die man sich vorstellen kann. 1231121331231312 sekktorenbelegung von dateien 1 2 und 3. das passt in meinen augen zu dem ansich sonst äußerst durchdachten system unix/linux nicht so sehr.

im grunde ist die druckerwarteschlange doch nur ein systemdienst, der zwischen dem userprogramm (drucken dialog resp. dateimanager) und der ausführenden hardware (drucker resp. festplatte) zwischengeschaltet ist und das eins-nach-dem-anderen-spiel spielt. was ist daran falsch? und das argument mehr-ebenen = weniger-preformance zieht wohl nicht, denn genau darum geht es ja, die bei großen datenmengen zu optimieren. wenn nur ein job anliegt ist die performance wohl mit der ohne wartschlange identisch.

was meinst du zu der idee?

gruß -increiond

Ich bin zwar nicht angesprochen, aber was solls. 😉

incredion schrieb:

wundert mich ein bisschen dass gerade das nicht nur multitasking- sondern auch noch multiuser-system unix sowas gar nicht hat. wenn da alle user gleichzeitig auf den massenspeicher zugreifen geht doch gar nichts mehr

Gerade in Mehrbenutzersystemen einer Größe, wo das überhaupt relevant wird, gibt es meistens dutzende bis zig Platten, auf denen die Daten verteilt sind, die zudem oft in RAID-Systemen zusammengeschlossen sind. Dass dabei überdurchschnittlich viele User zufällig genau auf eine davon zugreifen, dürfte eher selten sein.

Außerdem würden dann die "hinten anstehenden" Benutzer ewig auf ihre Dateizugriffe warten. Wegen z.B. eines großen Kopiervorgangs müssten dann viele kleine ungerechtfertigt lange warten. Das ist ähnlich des Vorteils von präemtivem Multitasking gegenüber kooperativem Multitasking.

Deine Idee ist im Gegenteil m.E. eher in einem Einzelbenutzersystem sinnvoll, als in einem Mehrbenutzersystem.

im grunde ist die druckerwarteschlange doch nur ein systemdienst, der zwischen dem userprogramm (drucken dialog resp. dateimanager) und der ausführenden hardware (drucker resp. festplatte) zwischengeschaltet ist und das eins-nach-dem-anderen-spiel spielt. was ist daran falsch? und das argument mehr-ebenen = weniger-preformance zieht wohl nicht, denn genau darum geht es ja, die bei großen datenmengen zu optimieren. wenn nur ein job anliegt ist die performance wohl mit der ohne wartschlange identisch.

Der Nachteil ist m.E., dass dann die eigentliche Datenverwaltung auf Dateiebene nicht mehr aufgabenspezifisch optimiert werden kann. Eine Datenbank behandelt ihre Dateien anders als ein Dateimanager. Auf Windows sieht man ganz gut, wieviel ein guter Dateimanager gegenüber den Systemroutinen herausholen kann. Gegenüber dem Windows Explorer benötigt z.B. der Total Commander bei identischen Kopiervorgängen nur einen Bruchteil der Zeit.

Der Vergleich mit einer Druckerwarteschlange hinkt ansonsten allein deswegen, weil ein Drucker nunmal immer nur ein Blatt gleichzeitig drucken kann, Dateizugriffe dagegen parallel stattfinden.

@incredion: Und um noch auf das Fragmentieren einzugehen: Die meisten Linux-Dateisysteme speichern die Blöcke nicht einfach so hintereinander, sondern Dateien werden zum Beispiel auf der Platte verteilt. Also wenn ich zwei Dateien A und B zum schreiben öffne und da abwechselnd Daten reinschreibe, dann werden dafür nicht Blöcke nach dem Muster abababababab auf der Platte abgelegt, sondern irgdendwo auf der Platte werden aaaaaaa geschrieben und ganz woanders bbbbbb. Es werden auch immer mehrere Blöcke im voraus reserviert. Aber selbst wenn das ababab-Muster irgendwo steht, ist das keine schlimme Fragmentation weil alleine die Festplatten das heutzutage in einem Rutsch in den internen Cache laden werden. Auf der Ebene wird nicht blockweise gelesen, sondern immer viele direkt aufeinanderfolgende Blöcke. Die aus dem RAM der Platte heraus zu lesen ist schneller als für jeden Block im schlimmsten Fall eine komplette Plattendrehung abwarten zu müssen. Fragmentierung ist nicht per se schlimm. Unter Linux wird es eigentlich nur problematisch, wenn die Platte nahezu voll wird, denn dann müssen die "Löcher" aufgefüllt werden, und es kann zu ziemlich "verteilten" Dateien kommen. Das ist der Zeitpunkt, wo man eine neue, grössere Platte kaufen sollte. ☺

das ist ja alles schön und gut.

Praxis ist aber: ich starte einen kopierauftrag (datei > 1 GB), der läuft sehr zügig, ich starte den zweiten (ebenfalls große Datei) und die Performance geht in den Keller.

@Blackjack: Da hilft die schöne Theorie mit Chaches und Co. nicht recht viel. Außerdem sind die üblichen 8 oder 16 MB Cache auf den Platten bei 1 GB-Dateien ebenso schnell voll und müssen geschrieben werden, wie die Bewegung der Köpfe die Performance drückte, wenn aaaa und bbbb Blöcke irgendwo auf der Platte verteilt geschrieben werden.

Habe den Eindruck, Du lässt Dich von vielen schönen techn Features blenden, die im Fall von sehr großen Dateien aber nur begrenzt was bringen.

@V:

eher in einem Einzelbenutzersystem sinnvoll

nichts dagegen. Dann sind wir schon einer Meinung. Die Einzelbenutzer-Nutzung ist sowieso die der Gegenwart und Zukunft, da die gute alte Mehrbenutzer-Nummer ja mehrheitlich dafür da war, dass man nicht für jeden Forscher an den Unis einen eigenen Großrechner anschaffen hat können... heutzutage rechnet jeder auf seiner eigenen Maschine und das wird sich kaum mehr ändern, weil die Kapazitäten im Vergleich zu den Kosten so enorm zugelegt haben.

RAID-Systemen

auch das ist doch zunehmend Vergangenheit im Desktopbereich. Bei einer Platte mit 1 TB brauche ich doch kein RAID. Ich weiß schon, Mirroring, Datensicherheit, etc. pp. alles bekannt, aber im Desktop ist das Over-the-Top und energetisch wie kostentechnisch völlig sinnlos. Da gibt es ein paar Performance-Freaks, die meinen ihre Arbeit dadruch zu beschleunigen, aber das ist Unsinn, wie Übertakten und Co. da reden wir von Performance-Unterschieden unterhalb der Wahrnehmungsschwelle.

Wir müssen schon damit rechnen, dass die Leute mit der Standard-config eines PCs arbeiten und das ist eine max. zwei Platten (ohne RAID). Bei Servern mag das anders sein, aber ich spreche hier immer von Desktop-Systemen.

Der Vergleich mit einer Druckerwarteschlange hinkt ansonsten allein deswegen, weil ein Drucker nunmal immer nur ein Blatt gleichzeitig drucken kann, Dateizugriffe dagegen parallel stattfinden.

eine Festplatte hat einen oder zwei Leseköpfe und die schreiben definitiv sequenziell. Und genau das ist doch die Krux: die Hardware muss die Zugriffe sequenziell abarbeiten, weil sie halt so aufgebaut ist, wie sie ist, das OS kommt aber daher und will mehreres geichzeitig (in engen Zeitscheiben) abwickeln. Flaschenhals → Problem. Mein Vorschlag ist deshalb eine Lösung, weil die Laufwerks-Warteschlange der Hardware helfen würde, sich unter dem Versuch parallele Anfragen in eine sequenzielle Bearbeitung zu drängen helfen würde. Jedenfalls würde es den sich selbst überlassenen Wildwuchs an Optimierungen und Caching-Konzepten, die ja wohl alle höchstens zufällig glücklich ineinandergreifen, aber wohl kaum aufeinander abgestimmt sind, ein bisschen steuern können.

Eine Datenbank behandelt ihre Dateien anders als ein Dateimanager

man kann nicht alles haben. Der Anteil an db-Zugriffen auf einem Desktop-Rechner hält sich in Grenzen. Natürlich ist mein Ansatz eine Lösung für genau das Problem, viele große Dateien hintereinander auf ein im Vergleich zu ihrer Größe langsames Medium zu kopieren. Aber das kommt meineserachtens relativ häufig (zunehmend häufiger, weil man immer unkritischer gegenüber immensen datenmengen wie Filme und Musik auf dem PC wird) vor.

gruß -incredion

@incredion: Bei dem Szenario helfen die Caches natürlich nicht, aber das ist auch nicht "normal". Selbst Leute die das tun, tun das nicht ständig und das Betriebssystem sollte eben mehr oder weniger vernünftig auf die normalen Operationen reagieren.

"Mehrbenutzerbetrieb" ist auch auf Einzelplatzrechnern der Normalfall, nämlich in Form von Multitasking. Stell Dir mal vor Du startest den Kopiervorgang von der 1 GB Datei, der dauert ja eine Weile und möchtest in der Wartezeit mal nach E-Mails schauen. Das geht dann aber nicht, wenn die Mails auf der gleichen Platte liegen, die gerade vom Kopieren "belegt" wird, und das Lesen der Maildateien in der Schlange nach dem Kopiervorgang eingereiht wird. Oft möchte man halt auch, trotz Leistungseinbruch, parallel zugreifen.

Das Betriebssystem hat keine Ahnung was eine Anwendung, die eine Datei öffnet damit vorhat. Es weiss nicht, wieviel, in welcher Geschwindigkeit, und in welcher Reihenfolge die Anwendung auf der Datei lesen oder schreiben wird. Wie genau soll man da eine Warteschlange einbauen, die letztendlich nicht auch nur rät und hoffentlich mit den ganzen anderen Ratemechanismen sinnvoll ineinandergreift?

Bei diesem Thema braucht man IMHO einfach den Endanwender, der solche Kopiervorgänge bewusst mit einer Software mit Warteschlangen anstösst.

incredion schrieb:

@V:

eher in einem Einzelbenutzersystem sinnvoll

nichts dagegen. Dann sind wir schon einer Meinung. Die Einzelbenutzer-Nutzung ist sowieso die der Gegenwart und Zukunft, da die gute alte Mehrbenutzer-Nummer ja mehrheitlich dafür da war, dass man nicht für jeden Forscher an den Unis einen eigenen Großrechner anschaffen hat können... heutzutage rechnet jeder auf seiner eigenen Maschine und das wird sich kaum mehr ändern, weil die Kapazitäten im Vergleich zu den Kosten so enorm zugelegt haben.

Im Gegenteil, heute ist Cloud_Computing für den Heimbereich groß im kommen - gerade auch für Ubuntu und in Firmen (und natürlich Unis) wird eh meist serverbasiert gearbeitet.

RAID-Systemen

auch das ist doch zunehmend Vergangenheit im Desktopbereich.

Ich bezog mich damit ja auch rein auf typische Mehrbenutzersysteme in Antwort auf Deinen Bezug auf diese. (puh, was für'n Satz 😉 )

Wir müssen schon damit rechnen, dass die Leute mit der Standard-config eines PCs arbeiten und das ist eine max. zwei Platten (ohne RAID). Bei Servern mag das anders sein, aber ich spreche hier immer von Desktop-Systemen.

Du hattest Dich zuvor gewundert, dass Warteschlangen in der von Dir gewünschten Form nicht im Multiuser-Unix/Linux-Bereich existieren. Darauf bezog sich die erste Hälfte meiner obigen Antwort. Nur bemerkt, um zu verhindern, aneinander vorbei zu diskutieren. ☺

Eine Datenbank behandelt ihre Dateien anders als ein Dateimanager

man kann nicht alles haben. Der Anteil an db-Zugriffen auf einem Desktop-Rechner hält sich in Grenzen.

Schließe nicht von Dir auf Andere. Außerdem wirkt oft eine Datenbank im Hintergrund. Firefox hat eine (SQLite), Musikplayer wie Amarok etc. haben welche usw. - Praktisch jede Anwendung, die mehr als nur eine Handvoll Einstellungen oder Daten verwaltet, ist sinnvollerweise mehr oder weniger datenbankbasiert.

Natürlich ist mein Ansatz eine Lösung für genau das Problem, viele große Dateien hintereinander auf ein im Vergleich zu ihrer Größe langsames Medium zu kopieren. Aber das kommt meineserachtens relativ häufig (zunehmend häufiger, weil man immer unkritischer gegenüber immensen datenmengen wie Filme und Musik auf dem PC wird) vor.

Also, ich habe recht große Datenarchive, kopiere diese jedoch nur selten herum. Und dann mag ich z.B. die Kopierwarteschlange von Krusader sehr. Aber im Alltag deswegen - wie Marc es schon beschrieb - ggf. spürbare Wartezeiten zu haben, nur weil eine "Hintergrund-Warteschlange" meine momentane Anwendung hinten anstellt? Nein danke. Du kannst davon ausgehen, dass 90% der Dateizugriffe Deines Systems nicht sequentiell ablaufen.

Man könnte auch mit der Konsole arbeiten um die Idee zu verwirklichen.

Mein Tipp: Wende dich mal an Ubuntu Brainstorm,solche guten und einfachen Ideen werden oft umgesetzt 😉