Herausfinden ob Dateien auf unterschiedlichen Festplatten liegen
-
Moin moin!
Zwecks multithreading ist es ja sicherlich nicht schlecht, wenn man bei einer Dateiverarbeitung herausfindet welche Dateien auf welcher Platte liegen um dann jede Platte mit einem eigenen Thread zu versehen. Nur... wie findet man - unter Linux - heraus, ob (zwei) Dateien auf unterschliedlichen Platten liegen? Wegen FUSE etc. kann man ja nicht einfach mal bei /media vorbeischauen
mfg
trigger
-
Jemand könnte noch eine Datei formatiert und im Dateisystem eingebunden haben. Alles ist eine Datei
Vielleicht könnte man so was ähnliches wie das Programm "mount" macht, feststellen, was wo "gemountet" ist und anhand dieser Information Entscheidungen treffen, ob Thread oder nicht...
-
Indem du die Ausgabe von
$ stat -c '%D' /pfad/zur/datei
für zwei Dateien vergleichst kannst du feststellen, ob beide Dateien im selben Dateisystem liegen oder nicht. Das liefert dir allerdings nicht die Information, ob die Dateien auf unterschiedlichen physikalischen Geräten liegen.Ich wüsste aber auch nicht, wie das so einfach gehen sollte. Physikalische Geräte liegen ziemlich weit unten in der Hierarchie, es könnte ja z.B. noch ein RAID draufsein und ein LVM, dann ist allein aus dem mount-Befehl noch unklarer, welche (und wieviele) Geräte hinter einem bestimmten Dateisystem stecken.
-
Vielen Dank!
Vielleicht nicht elegant, aber hilfreich!
-
Christoph schrieb:
Ich wüsste aber auch nicht, wie das so einfach gehen sollte.
Und mit wieviel Aufwand waere es moeglich?
Ich habe zB ne lvm Partition aus mehreren physikalischen Platten und will ein atomic mv darauf machen - kann ich das irgendwie herausfinden ob das geht? Weil die alternative mit locking ist nicht so toll
-
Nur so ne Zwischenbemerkung: Sollte das Dateisystem von Linux nicht genau davon abstrahieren?
-
knivil schrieb:
Nur so ne Zwischenbemerkung: Sollte das Dateisystem von Linux nicht genau davon abstrahieren?
Ja. Genau deswegen ist es ja auch so schwer so etwas herauszufinden. Die genannten Lösungen funktionieren nämlich alle nicht zuverlässig. Wenn man parallel schreiben möchte, macht man dies normalerweise auf einer tieferen Abstraktionsebene, indem man ein paralleles Dateisystem aufsetzt. Auf Anwendungsebene, wie hier gefragt, haben solche Überlegungen eigentlich nichts zu suchen.
-
Gerade festgestellt man kann ja stat auch ohne kommandozeile nutzen! sys/stat.h Sehr gut!
[quote="SeppJ"]
knivil schrieb:
Auf Anwendungsebene, wie hier gefragt, haben solche Überlegungen eigentlich nichts zu suchen.
Aber verstehe ich das richtig? Das bedeutet doch im Umkehrschluss, wenn ein Programm nicht will, dass Kapazitäten bei CPU und Festplatten ungenutzt bleiben, ist das bad practice? o.0
-
Trigger_Hurt schrieb:
Aber verstehe ich das richtig? Das bedeutet doch im Umkehrschluss, wenn ein Programm nicht will, dass Kapazitäten bei CPU und Festplatten ungenutzt bleiben, ist das bad practice? o.0
Was geht es ein Anwendungsprogramm an, wie ich meine CPU-Kerne und Datenträger belasten will? Das ist Sache des Schedulers und des Dateissystems. Da kann der Administrator zentral verwalten, was sich wie zu verhalten hat. Und wer sagt mir, ob die Entscheidungen die dein Anwendungsprogramm da treffen will a) heute schon richtig oder b) auch in Zukunft noch richtig sind?
-
Vielleicht reden wir an einander vorbei:
Mein Programm wird recht rechen- und festplattenintensiv. Da bietet sich multicore-optimierung doch an. Da wohl eher die Festplatten den Flaschhals bilden, wäre es doch praktisch, wenn nicht immer nur eine nach der anderen beschäftigt ist, zumindest als optionales Feature (fälschliches multithreading bei einer (!) Festplatte ist ja wohl auch eher kontraproduktiv); ich habs teilweise auch gern, wenn man gezielt Festplatten beanspruchen/nicht beanspruchen kann.
Als normales Programm wollte ich am schedulen auch nix drehen
-
Dann lass den User doch mehrere temp-Verzeichnisse angeben.
