Frage "Used Space" ändert sich nach dem Schrumpfen der Partition


Ich habe meinen Laptop mit einem Kubuntu 16.04 live USB gebootet und mit dem KDE Partition Manager (Version 1.2.1) die interne HDD (/ dev / sda) angeschaut. Die Hauptpartition (/ dev / sda3, ext4) war 442,91 GiB und Partition Manager berichtete, dass 41,29 GiB verwendet wurde.

Ich benutzte dann KDE Partition Manager, um sda3 auf 45 GiB zu verkleinern. Nachdem das Schrumpfen erfolgreich abgeschlossen wurde (keine Fehler gemeldet), berichtete KDE Partition Manager, dass 35.03 GiB verwendet wurde. Die Daten auf der Partition sollten sich nicht geändert haben. Wie ist das passiert?

Eine (nicht besonders informierte) Vermutung von mir wäre, dass der Partition Manager mir tatsächlich eine "Schätzung" des genutzten Platzes gegeben hätte, der sich nach der schrumpfenden Operation verbessert hat; d.h. die tatsächlichen Daten waren immer näher bei 35 GiB. Oder vielleicht wurden viele Daten im Papierkorb oder in den temporären Ordnern entfernt. Aber das ist immer noch ein großer Unterschied (etwa 20 Prozent), also habe ich mich gefragt, ob irgendjemand das schon einmal gesehen hat oder tatsächlich weiß, warum das passiert / erwartet werden sollte.

Aktualisieren: Der Laptop scheint zu booten und funktioniert gut nach dem Schrumpfen. Dies ist natürlich kein Beweis, aber es gibt keine Hinweise auf Datenverlust.

Update 2: Die Anzahl der verwendeten Inodes ist zwischen "shrunk" und "unsrunk" identisch, und ein Vergleich der Prüfsummen aller Dateien zeigt keine Unterschiede. Daher bin ich noch sicherer, dass es keinen Datenverlust gegeben hat, was die größte praktische Sorge war. Die Frage ist noch offen, ist aber an dieser Stelle akademischer.


1
2018-02-10 16:58


Ursprung


ext4 speichert Daten nicht sequentiell. War der Antrieb montiert, als Sie ihn schrumpften? Datenverlust ist eine Möglichkeit. - ravery
@ravery Partition Manager hätte es nicht erlaubt ext4 zu verkleinern, wenn es gemountet wurde. Es erlaubt, es während der Montage wachsen, aber das ist in Ordnung. Btrfs können sowohl vergrößert als auch verkleinert werden, wenn sie aktiviert sind. In der Tat ist das die einzige Möglichkeit, die Größe von Btrfs zu ändern. Sie können die Größe der Btrfs nicht ändern, wenn Sie sie aushängen. - Andrius Štikonas
@ravery, es wurde nicht montiert. - Ratler


Antworten:


Der KDE-Partition-Manager bezieht den belegten Speicherplatz von einigen wenigen Quellen, von denen einige Schätzungen sein können. Aber wie du gesagt hast, 20% sieht ein bisschen zu viel aus.

Ich denke, eine andere Sache ist, dass die Tools zur Änderung der Partitionsgröße einige Disk-Strukturen wie die Anzahl der Extents ändern können, so dass Sie weniger Speicherplatz zum Speichern von Metadaten benötigen.


1
2018-02-11 17:22



Sind die Ausdehnungen mit Fragmentierung verbunden (das habe ich nach einer schnellen Suche herausgefunden)? Gibt es eine einfache Möglichkeit, die Metadatenhypothese zu überprüfen (nur aus Interesse)? Ich habe montierbare gddrescue Bilder von der unshrunk und geschrumpften Partition, und sie scheinen zu arbeiten. - Ratler
Sie können versuchen, mit dumpe2fs zu spielen und zu sehen, ob Sie Metadaten-Informationen erhalten können. Ich habe nicht untersucht, welche Ausmaße im technischen Sinne sind, also ist mein Wissen nach einer schnellen Suche ähnlich. - Andrius Štikonas
Ich habe es geschafft, die Zwischendatei zu korrumpieren, also kann ich das nicht zum Vergleich verwenden. Beim Vergleich der nicht-geschrumpften und geschrumpften Bilder mit dumpe2fs konnte ich nichts sehen, was diese Art von Unterschied erklären würde (z. B. Inoden oder reservierte GDT-Blöcke sind nicht annähernd so groß wie der Unterschied). - Ratler


Der Unterschied tritt aufgrund der reserved-blocks-percentage Das ist ein Parameter des Dateisystems. Das reserved-blocks-percentage kann mit dem geändert werden tune2fs-Befehl und hat einen Standardwert von 5% (siehe man tune2fs, Suche nach -m-Möglichkeit).

Es sieht so aus, als ob Ihr Dateisystem vor der Bearbeitung der Partition auf 2% eingestellt wurde und während der Größenänderung auf 5% zurückgesetzt wurde.


1
2018-03-08 18:49



Ich habe überprüft und sowohl die Unschrunk und Schrumpf haben genau 5% reservierte Blöcke (etwa 22 GiB bzw. 1,9 GiB). Werden die reservierten Blöcke als belegter Speicherplatz angezeigt? - Ratler
Ich dachte, Sie könnten da etwas machen, aber die Zahlen addieren sich immer noch nicht: Wenn die volle Partition etwa 22 GiB in reservierten Blöcken hatte und sich nach der ersten Verkleinerungsoperation auf etwa 2,2 GiB änderte, würde das ungefähr 20 freigeben GiB von Raum, was viel mehr ist als die 6 GiB Änderung, die ich gesehen habe (es sei denn, nur ein Teil der reservierten Blöcke wird als "benutzter Raum" gemeldet ...). - Ratler
@Ratler Ja, die reservierten Blöcke werden als belegter Speicherplatz angezeigt. Ich denke, Ihr Dateisystem wurde vor der Größenanpassung auf 2% gesetzt, aber das können wir nicht mehr überprüfen, die Größe der Partition wurde bereits geändert ... - mook765
Ich habe vor der Größenänderung ein Backup-Image der Partition erstellt. So konnte ich die Anzahl der reservierten Blöcke überprüfen: 5805286 (~ 22,2 GiB) für die nicht schrumpfende Partition und 498072 (~ 1,9 GiB) für die geschrumpfte Partition. (Ich habe versehentlich das Image der Zwischenpartition beschädigt, daher kann ich das nicht direkt überprüfen, aber basierend auf den anderen beiden gibt es keinen Grund zu der Annahme, dass es sich um etwas anderes als 5% handelt.) - Ratler
Ich weiß nicht, wie Sie die Parameter eines Dateisystems überprüfen, das sich in einer Bilddatei befindet. Versuchen Sie jedoch einige Tests: Erstellen Sie eine Partition (oder verwenden Sie eine vorhandene Partition) und spielen Sie mit dem reservierten Blockprozentsatz herum. Überprüfen Sie auch, was der KDE-Partitionsmanager unter verschiedenen Bedingungen meldet. Wahrscheinlich hilft Ihnen ein solcher Test, etwas zu sehen. - mook765