Fragmentierung der heruntergeladenen Dateien
-
Hallo, erstmal möchte ich sagen ich finde das Programm echt genial, jedoch ist mir aufgefallen das die heruntergeladenen dateien sehr stark fragmentiert sind, so um die 40.000 fragmente pro datei. das hat meine externe HDD Komplett lahmgelegt, sodass ich auf meine SSD gewechselt habe. woran liegt denn diese sehr starke fragmentierung der dateien?
-
@matrix sagte in Fragmentierung der heruntergeladenen Dateien:
woran liegt denn diese sehr starke fragmentierung der dateien?
An deinem PC bzw. an deinem BS? O.o
MediathekView Entwickler | Bugs?: Anleitung Fehler melden | Fehlende Sendungen?: Fehlende Sendung melden
-
@nicklas2751 sagte in Fragmentierung der heruntergeladenen Dateien:
@matrix sagte in Fragmentierung der heruntergeladenen Dateien:
woran liegt denn diese sehr starke fragmentierung der dateien?
An deinem PC bzw. an deinem BS? O.o
Das verwendete Dateisystem dürfte auch eine Rolle spielen.
-
Guten Morgen,
im schnitt mache ich 3 downloads gleichzeitig, bis zu 6 stück hab ich eingestellt. Dateisystem ist NTFS, os ist win 10 pro x64 (RS4). bisher hatte ich es so extrem noch nie, ich kenne zwar das dateien fragmentiert heruntergeladen werden, aber ich hatte antwortzeiten von 15.000 ms bei meiner hdd und 3.1 millionen fragmente bei nicht mal 300gb, das ist echt extrem und kenn ich so nicht, genug speicher war auch vorhanden und fragmentierung vorher war 0% da die platte recht frisch defragmenteniert war. ich kann mir das nicht wirklich erklären. -
@matrix
Prüf´ doch mal, ob die automatische Defragmentierung für die HDD eingeschaltet ist. Windows defragmentiert standardmäßig im Hintergrund, schaltet die Funktion aber ab, wenn eine SSD erkannt wird, da hier die Fragmentierung gewünscht ist um die Schreibzeiten zu optimieren und durch eine zusätzliche Fragmentierung die Lebensdauer sinkt. Programme kommen normalerweise nicht so tief in das Dateisystem, um die exakte Schreibposition festzulegen, daher wird die Ursache im Betriebssystem zu suchen sein. Natürlich braucht Windows dafür auch etwas Leerlaufzeit, denn wenn der Rechner nur zum Speichern läuft, wird i.d.R. nicht defragmentiert (das steht aber alles im Zeitplan für die Defragmentierungs-Aufgabe) -
@matrix Du kannst dir mit “Contig64.exe -a *.mp4” aus den Windows Sysinternals die Anzahl der Fragmente einzelner Dateien anzeigen lassen.
Um die Anzahl der Fragmente nicht unnötig groß werden zu lassen, benutze ich beim Formatieren meiner Daten-Partitionen mit NTFS den Maximalwert “64 KB” als Größe einer Zuordnungseinheit statt der Standardgröße “4096” Bytes. -
Ich habe die windows defragmentierung durch defraggler ersetzt, daher sollte die automatische defragmentierung ausgeschaltet sein, oder? ich lade eigentlich recht viel runter (aus legalen quellen), teilweise über 100gb am tag und hatte bisher noch nie solche probleme, ich hab zwar auch dateien mit 4000 fragmenten, aber halt nicht mit 40.000. defragmentieren tu ich auch regelmäßig, weil wenn ich über steam runterlade sind die dateien auch nicht automatisch defragmentiert, aber mediathek view hat mir echt die platte lahm gelegt. wenn ich die dateien dann sortiert und verschoben habe (auf eine andere patition) ist es auch nicht mehr so heftig und die dateien sind nicht bzw. normal fragmentiert.
mir gehts hauptsächlich darum das ich jetzt auf die ssd downloaden muss und ich da nicht mal mehr 100gb frei habe und ich so mehrmals am tag die dateien einsortieren muss, wie gesagt danach ist die fragmentierung normal, aber unbeaufsichtigt downloaden ist halt nicht unbedingt möglich da ich dann sehr schnell die systemfestplatte voll habe.
ich formatiere immer auf standard, da ich früher viel mit beschädigten hdds gearbeitet habe bzw. arbeiten musste und wenn dann ein sektor platt war ging meistens die ganze zuordnungseinheit flöten und dadurch war die datei dann ernsthaft beschädigt da hat auch lowlevel remapping nix mehr genutzt, daher bin ich immer noch auf der vorsichtigen seite auch wenn ich nur noch neue hdds habe und auch seit 2009 kein XP mehr benutze, was immer gerne probleme gemacht hat beim verschieben und kopieren von großen datenmengen.
aufgefallen ist mir das ganze nur dadurch das ich beim verschieben grausame geschwindigkeiten hatte und beim zugriff auf die platte bei 1mb´s schon auf 100% auslastung war und einmal sogar 55.000ms reaktionszeit hatte (hab ich vorher noch nie erlebt) und dann hab ich mit defraggler die hdd geprüft und mir die fragmentierten dateien angeschaut und bei 3.1 millionen fragmenten bei 300 dateien hab ich mich dann auch nicht mehr gewundert, seitdem die daten einsortiert sind läuft alles wieder normal.
-
@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.
