terkisch schrieb:
Ist es evtl möglich zu sehen, wie viel Speicher in der erweiterten Partition belegt ist?
Achso, was man vielleicht machen kann - man kann Pi mal Daumen abschätzen, wieviele verschlüsselte Daten, vs. unverschlüsselte/Nullen.
Bei einer SSD, und LUKS mit allow-discards, und fstrim, wäre freier Speicher auf der SSD wahrscheinlich Null. Und Nullen kann man prima komprimieren. So kann man dann vielleicht doch (ganz grob) abschätzen, wieviel ist belegt, wieviel ist frei.
Das Script hier liest die Rohdaten ein, und schickt diese durch ein Komprimierungsprogramm (lzop --fast, kannst auch gzip oder sonstwas nehmen). Dann zählt es (mit pv) unkomprimierte vs. komprimierte Daten.
Bei 100% verschlüsselte Daten ohne TRIM wären beide gleich. Verschlüsselte Daten kann man nicht komprimieren.
Gibt es freie / unverschlüsselte Bereiche, dann sind die komprimierten Daten entsprechend weniger.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16 | #!/bin/bash
#
# check how much encrypted data vs. trimmed areas
#
target="$1"
if [ -b "$target" ]
then
size=$(blockdev --getsize64 "$target")
else
size=$(stat -c "%s" "$target")
fi
pv -cN input < "$target" | lzop --fast | pv -cN output --size="$size" > /dev/null
|
Beispiel mit 100% verschlüsselt / Zufallsdaten (bleibt immer gleich auf, oder output wird sogar etwas größer):
input: 73.4GiB 0:00:44 [1.60GiB/s] [=======> ] 31% ETA 0:01:35
output: 73.4GiB 0:00:44 [1.60GiB/s] [=======> ] 31% ETA 0:01:35
Beispiel mit Nullen:
input: 8.00GiB 0:00:03 [2.06GiB/s] [===========================>] 100%
output: 3.68GiB 0:00:03 [ 969MiB/s] [============> ] 46%
Hier war die Datei 8G groß, aber ließ sich auf 3.68G runter komprimieren. Bei Verschlüsselung könnten dann nicht mehr als 3.68G Daten darin versteckt gewesen sein.