Hi Ich mach gerade einen Test mit einer Festplatte. Die Festplatte ist voll, es wird 0b Restkapazität angezeigt und es können keine Dateien mehr darauf kopiert werden. Ich kann jedoch eine leere txt Datei erstellen und später mit Text füllen. Ich hab mittelerweile einige txt Dateien erstellt, allesamt haben bereits über 10MB. Wird hier nun was gelöscht, oder hat die Platte noch einen gewissen Puffer für solche Aktionen?
Beitrag #6485154 wurde vom Autor gelöscht.
Hallo welches Betriebssystem? Hier hat es auf jeden Fall unter Windows 10 und einer nicht System HD nicht mal für ein wenige 100kByte großes Bild gelangt als die Platte voll gemeldet wurde. Allerdings wurde die HD immer "sauber" gehalten, sprich der Papierkorb (also nur aus dem Festplattenverzeichniss aber nicht wirklich gelöschte Dateien) immer richtig gelöscht. Insgesamt gibt es aber gefühlt ;-) ein dutzend und mehr Möglichkeiten die verschiedensten Einstellungen (teils gar nicht bewusst oder irgendwann mal so angelegt und dann vergessen) zu machen wie Win10 mit Festplattenspeicherplatz umgeht und auch eventuell "versteckt" frei hält. Jemand
Du hast leider nicht angegeben um welches Filesystem es sich handelt. Eine ganze Reihe von denen reserviert einen festen Bereich für die Dateiverwaltung (Da sind die u.a. Dateinamen und die Verweise auf die Position der eigentlichen Daten drin). Deine Leere Datei landet erstmal nur in diesem Bereich. Einge FS speichern kleine Dateien sogar ganz in den Verwaltungsbereich. z.B. mal hier einlesen: https://de.wikipedia.org/wiki/NTFS https://en.wikipedia.org/wiki/Sparse_file
Simon schrieb: > Die Festplatte ist > voll, es wird 0b Restkapazität angezeigt und es können keine Dateien > mehr darauf kopiert werden. Ich kann jedoch eine leere txt Datei > erstellen und später mit Text füllen. Ich hab mittelerweile einige txt > Dateien erstellt, allesamt haben bereits über 10MB. buffered IO, es ist möglich das der Text lediglich im (RAM-) buffer gespeichert ist und nicht auf der Platte, ein fflush() würde scheitern. https://docs.microsoft.com/de-de/cpp/c-runtime-library/reference/fflush?view=msvc-160
Simon schrieb: > Ich hab mittelerweile einige txt Dateien erstellt, allesamt haben bereits > über 10MB. Du hast 10 MB Text geschrieben? Das ist ungefähr doppelt so viel wie die Bibel. Oder was hast du genau gemacht, um da 10 MB rein zu bekommen?
Verbrauchsguttester schrieb: > buffered IO, es ist möglich das der Text lediglich im (RAM-) buffer > gespeichert ist und nicht auf der Platte, ein fflush() würde scheitern. Die Allokation von Plattenplatz erfolgt nicht erst, wenn die Daten vom Puffer zur Disk wandern, sondern bereits vorneweg im RAM. Das System muss ja wissen, wohin das Zeug soll. Wenn es nicht reicht, dann also sofort, nicht verzögert. File-Nodes sind je nach Filesystem teilweise oder vollständig voralloziert, brauchen also nicht notwendigerweise zusätzlich Platz. Leere Files brauchen auch keinen Platz für Daten. Komplexer wird es bei Directory-Einträgen, die auf diese File-Nodes verweisen.
:
Bearbeitet durch User
es ist eine Platte auf einem NAS, formatiert mit Btrfs. Ich arbeite an einem W10 PC Die Text Dateien hab ich jeweils mit ctrl-c bzw ctrl-v gefüllt. Also sobald eine Seite voll war diese kopiert und einige Male eingefügt, dann den ganzen Krempel wieder kopiert und wieder eingefügt usw.
Simon schrieb: > formatiert mit Btrfs Das ändert so ungefähr alle Aussagen oben. COW-Filesysteme arbeiten deutlich anders als konventionelle. https://ohthehugemanatee.org/blog/2019/02/11/btrfs-out-of-space-emergency-response/ Welche NAS verwendet btrfs?
:
Bearbeitet durch User
Weitere Besonderheiten von btrfs und Plattenplatz: http://marc.merlins.org/perso/btrfs/post_2014-05-04_Fixing-Btrfs-Filesystem-Full-Problems.html
Simon schrieb: > es ist eine Platte auf einem NAS, formatiert mit Btrfs. Ich arbeite an > einem W10 PC und wahrscheinlich mit smb. In der Kombination kann die Anzeige der Plattenbelegung vom Speichern selbst total entkoppelt sein (das war zumindest früher so). Zum Beispiel ist ein Verzeichnis auf der (vollen) root-Partition freigegeben, Windows sieht also 100%. Aber unter dem Verzeichnis ist eine zweite Partition gemountet und da ist noch Platz. Man konnte deshalb in Samba ein Script einbinden, das genauere Daten liefern sollte. Aber dessen Ausgabe war auch fragwürdig, weil meistens gepuffert. Windows cached auch heftig (wegen ein paar Dutzend MB belastet man doch nicht das Netzwerk) und evt. löscht der User die Dateien ja gleich wieder.
Bauform B. schrieb: > eine zweite Partition gemountet und da ist noch Platz. Vorsicht mit solchen gemounteten Sachen. Mal nachsehen ob diese bei einem Backup wirklich mit gesichert wurden, wäre durchaus nützlich (bevor man im Störfall mit leeren Händen dasteht).
Nur eine Idee - Wärs eine Option, mit einer Live-CD die HDD "von der Seite" zu analysieren und auf Verstecktheiten zu prüfen - eingebettete FS in FS?
taking the data in those blocks, and putting it in fuller blocks so that you end up being able to free the less used blocks. Das klingt nach einer sehr üblichen Prozedur. Sokoban-Tetris-Dampfwalze macht aus Kohlenstaub Diamante = verdichten, komprimieren, defragmentieren .. such Dir ein Wort aus
(prx) A. K. schrieb: > Simon schrieb: >> formatiert mit Btrfs > > Das ändert so ungefähr alle Aussagen oben. Da mal ne brauchbare deutschsprachige Kurz-Erklärung zum butter-fs: https://www.heise.de/ct/artikel/Das-Dateisystem-Btrfs-221863.html?seite=all
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.