Fragmentierung der heruntergeladenen Dateien
-
@matrix sagte in Fragmentierung der heruntergeladenen Dateien:
die windows defragmentierung durch defraggler
Ich nutze Windows 10 und Ubuntu mit NTFS und ext4 und habe bei beiden seit Jahren schon nicht mehr defragmentieren müssen. Aber jeder wie er mag. Da wir mit MV nur die Java Standardmöglichkeiten zum schreiben von Datein nutzen bzw. je nach Sender ab und zu mal noch ffmpeg das übernehmen lassen kann das nichts MV spezifisches sein.
Oder Kurz gesagt, wir können dir da nicht helfen und haben darauf auch garkeinen Einfluss. Du solltest also eher mal dein Setup checken.
-
@Nicklas2751
So ganz stimmt das nicht. Man kann Windoof mitteilen, dass es den Speicherplatz schon reservieren soll. Das geschieht dann, sofern möglich, als zusammenhängende Blöcke.Ich weiß da von:
C++ SetEndOfFile
C# FileStream.SetLengthUnd in Java geht das laut kurzem Googlen wie erwartet natürlich auch mittels RandomAccessFile.setLength.
@Matrix
Welches Windows nutzt du denn? Spätestens seit Windows 8 ist es völlig überflüssig auf externe Defragmentierungstools zurückzugreifen. Meist sogar weniger effektiv als das Windows interne. -
@bagbag sagte in Fragmentierung der heruntergeladenen Dateien:
@Nicklas2751
Das geschieht dann, sofern möglich, als zusammenhängende Blöcke.Das ist der Punkt. Und es ist auch überhaupt nicht die Aufgabe einer Endanwendung sich um solche Dinge kümmern zu müssen.
-
Nutzt ihr setLength? Falls ja, dann gebe ich dir recht, dann ist alles diesbezüglich drin, was in das Aufgabengebiet einer Endwandung gehört.
Edit: Nein (außer da gibts noch ne andere Methode), dann gehört das meiner Meinung noch mit rein um dieses Problem zu lösen.
Edit²: MV scheint FileOutputStream zu nutzen (siehe GitHub). Da gibts laut den Java Docs kein setLength, also müsste man das umbauen auf RandomAccessFile.
-
.setLength ist eine tolle Sache wenn man die größe der Datei kennt. Aber es ist dann schlecht wenn das Programm beim DL unterbrochen wird. Durch setLength kann man dann nicht mehr ohne weiteres weiter laden da er nicht mehr weiß wo man aufgehört hat.
Grundsätzlich ist das ganze aber in der Tat ein Problem vom Windows VFS layer, welches mit write ops != 64K nicht wirklich gut zurecht kommt. Abseits von windows kommen wirklich alle anderen OS damit ohne Probleme zurecht (Solaris, Linux, macos, FreeBSD). Win quittiert das ganze mit ungefähr 30% weniger Leistung beim Schreiben - und offensichtlich evtl einem höheren Fragmentierungsgrad.
Letztendlich ist das aber nicht das Problem von unserem Code bzw Java an sich, da dieses die Schreiboperationen über die entsprechenden native API an das Windows VFS übergibt.
Evtl kann ich in der nächsten Version mal einen 64K buffer einbauen um Windoof zu befriedigen.
Davon abgesehen halte ich aber wie gesagt nicht wirklich viel davon, wieder einen Sonderweg zu programmieren weil ein OS es seit Windows NT immer noch nicht gelernt hat, seinen File System cache vernünftig einzusetzen. -
Ja, das Dateisystem von Windoof ist schrecklich, das bestreite ich nicht. Aber der Aufwand um Windoof da etwas unter die Arme zu greifen ist ja minimal.
Die Dateigröße gibt es doch (zumindest meistens) über die HTTP-Header. Den Downloadfortschritt könnte man - so wie es viele andere Download-Programme auch machen - in einer 2. Datei speichern.
Das Problem mag zwar nicht direkt in MV liegen, doch hat MV das Problem, dass manche Nutzer dadurch unzufrieden sind.
Das ganze würde auch Linux/Mac zu gute kommen, auch wenn deren Handhabung von Fragmentierung von Haus aus viel besser ist.
-
Hallo zusammen,
um die Fragmentierung zu vermeiden, versuche ich bei größeren Downloads grundsätzlich immer nur eine Datei pro Windows-Partition zum Schreiben offen zu haben, sprich pro Partition nur maximal einen Download gleichzeitig durchzuführen. Egal mit welchem Programm der Download erfolgt.
Diese Aussage zeigt aber auch eine Lösung für mehrere gleichzeitige Download auf: Man muss sie nur auf mehrere Festplatten(partitionen) verteilen. Dann kommen sich die einzelnen Downloads nicht gegenseitig in die Quere.
Eine andere Möglichkeit ist, für alle (gleichzeitigen) Downloads eine temporäre Partition zu verwenden und anschließend nacheinander auf die gewünschte Partition zu verschieben. Die auf der temporären fragmentierten Dateien werden auf der gewünschten Partition dann (nach Möglichkeit) zusammenhängend gespeichert. Werden alle (neuen) Dateien von der temporären Partition gelöscht, ist auch da nichts mehr fragmentiert.
Hallo Nicklas2751,
davon unabhängig ist es - wie schon meine Vorredner aufgezeigt haben - für eine Anwendung sehr leicht, schon beim Öffnen einer Datei genügend Platz zu reservieren und so das Fragmentieren zu verhindern. Bei einem Programm, dass die Möglichkeit bietet, mehrere große Downloads gleichzeitig durchzuführen, sehe ich das sogar - wenn schon nicht als erforderliches - so doch mindestens als sehr wünschenswertes Feature an. Und eben eins, dass sich mit sehr wenig Aufwand einbauen lässt.
herbivore
-
@herbivore sagte in Fragmentierung der heruntergeladenen Dateien:
um die Fragmentierung zu vermeiden, versuche ich bei größeren Downloads grundsätzlich immer nur eine Datei pro Windows-Partition zum Schreiben offen zu haben
Das ist Voodoo und nicht zielführend. Windows hat zu jeder Zeit eine Unmenge von Dateien offen und ein weiterer Download fällt da nicht ins Gewicht. Helfen könnte das Umkopieren der fertigen Datei, aber auch hier gibt es eine Vielzahl von Prozessen, die dagegen sprechen. Beispielsweise ist nicht gesagt, dass das Kopieren Rücksicht auf die Fragmentierung nimmt. Es könnte genau so gut exakt an die aktuelle Plattenposition geschrieben werden, an der sich der Schreib/Lesekopf gerade befindet. Mein Win7 in der Arbeit läuft seit 8 Jahren ohne manuellen Eingriff und zeigt 0% Defragmentierung, allerdings läuft die halt als Hintergrundprozess, ohne, dass ich davon etwas spüre.
-
Hallo MenchenSued,
was ich gesagt habe, hat nun wirklich nichts mit Voodoo zu tun, sondern ergibt sich direkt aus grundlegenden Eigenschaften von Datei- und Betriebssystem. Und auf anderen als der Systempartitionen hat Windows mitnichten viele Dateien offen, schon gar nicht zum Schreiben. Wenn du kein Problem mit Defragmentierung hast, freut mich das für dich ehrlich. Der Thread-Starter hatte jedoch eins und vielleicht noch andere Benutzer. Daher halte ich meine Ratschläge aufrecht. Auch wenn ich nie behauptet habe, dass dies die einzigen denkbaren oder möglichen Lösungen sind.
herbivore
PS:
Windows hat zu jeder Zeit eine Unmenge von Dateien offen und ein weiterer Download fällt da nicht ins Gewicht.
Was mir gerade noch auffällt: Das bestätigt genau, was ich auch sage. Zumindest steht es damit nicht im Widerspruch. Wenn man nur einen Download pro Partition hat, ist alles gut. Es ging nicht darum, dass sich ein Download und Windows ins Gehege kommen, sondern es ging darum zu vermeiden, dass mehrere große gleichzeitige Download untereinander Fragmentierung verursachen.
-
Nutzt einfach eine SSD und es ist gut. Ihr geht mir mit dieser Diskussion langsam echt auf die Nerven. MediathekView wird nicht für so einen Schwachsinn umgebaut. Ich denke auch nicht, dass eine Reservierung nicht auch fragmentiert werden könnte.
