[honx]

darf ich es wagen, ein virtual disk image von virtualbox mit linux mint darauf, nachträglich zu vergrössern? nach erstem googeln scheint es ja prinzipiell möglich zu sein, die frage ist daher nicht primär, ob ich es kann, sondern ob ich es wagen darf. ich will da nix kaputt machen und auf gar keinen fall neu aufsetzen.

das problem ist nämlich folgendes: als ich im august 2018 linux mint als vm aufgesetzt habe, bin ich den offiziellen "systemanforderungen" gefolgt, welche besagten, dass man für linux mint 20gb braucht. da ich seit jeher unter chronischem speicherplatzmangel leide, hab ich damals eben exakt jene 20gb als image-grösse definiert und keinen byte mehr.

nun hab ich allerdings das problem, dass nach all den updates in den letzten zwei jahren das ding langsam vollläuft. gegenwärtig sind von besagten 20gb nur noch 800mb frei. und das macht mir natürlich so allmählich sorgen.

übliche säuberungsmassnahmen, welche ich so gefunden habe, hab ich bereits ausgeführt. zumindest jene, welche ich gewagt hab:
sudo apt-get autoremove
sudo apt-get autoclean
sudo apt-get clean

die einzigen softwarepakete, welche ich persönlich dazuinstalliert habe, lassen sich auf einer hand abzählen: youtube-dl, mocp (mp3-wiedergabe in der kommandozeile), audacity und möglicherweise den midnight commander (da bin ich mir nicht sicher, ob der bei linux mint bereits enthalten war oder ob ich ihn nachgerüstet habe). das wars. ja, und entsprechende abhängigkeiten jener vier pakete, das kann allerdings nicht soviel ausmachen...

mir ist übrigens aufgefallen, dass /var/tmp ganze 900mb schluckt. hab es jedoch nicht gewagt, dort irgendwas zu löschen...

[foobar]

Habe es schon mehrfach gemacht und hatte keine Probleme damit. Halte dich an die Anleitung, dann klappt’s auch.

In der VM kannst du auch nochmal den lokalen Usercache (~/.cache) löschen. Da sammelt sich gerne Müll an, aber der Ordner sollte bedenkenlos geleert werden können. Du kannst außerdem in diversen Ordnern (bspw. /var/tmp) mal gucken, welche Dateien lange nicht mehr angefasst wurden. Die werden dann vermutlich nicht mehr gebraucht.

find /var/tmp -type f -atime +365 -delete

Löscht bspw. alle Dateien, auf die seit einem Jahr nicht mehr zugegriffen wurde.

Mit Programmen wie baobab oder filelight kannst du dir außerdem die Festplattenbelegung schön visualisieren lassen, um die größten Platzfresser zu ermitteln. Ich vermute, dass das primär nicht das Linux selbst, sondern dein Homeverzeichnis sein wird (Cache, Downloads, etc.)

[honx]

thx, welche anleitung würdest du empfehlen bzgl. vergrösserung? ich finde auf anhieb mehrere.

darf ich deinen befehl auch auf var/log anwenden? hab mich im einleitungspost nämlich vertippt.
nicht /var/tmp frisst 900mb, sondern /var/log.
ich hab vorerst mal nur den find-part ohne delete ausgeführt (find /var/log -type f -atime +365):

/var/log/timeshift/2018-09-14_00-20-54_gui.log
/var/log/timeshift/2018-08-13_20-03-19_gui.log
/var/log/tallylog
/var/log/ubuntu-system-adjustments-adjust-grub-title.log
/var/log/ubuntu-system-adjustments-stop.log
/var/log/fontconfig.log
find: ‘/var/log/speech-dispatcher’: Keine Berechtigung
/var/log/dpkg.log.12.gz
/var/log/mintsystem.log
/var/log/bootstrap.log
/var/log/apt/term.log.12.gz
/var/log/apport.log.7.gz
/var/log/ubuntu-system-adjustments-start.log
/var/log/apport.log.5.gz
/var/log/apport.log.6.gz
/var/log/gpu-manager.log
/var/log/alternatives.log.12.gz
/var/log/boot.log
/var/log/installer/media-info
/var/log/installer/partman
/var/log/installer/syslog
/var/log/installer/casper.log
/var/log/installer/debug
/var/log/installer/initial-status.gz
/var/log/installer/version

das gesamte /home/user verzeichnis ist insgesamt nicht grösser als 150mb:

1157 Objekte der Gesamtgröße 143,4 MB
(einige Inhalte unleserlich)

downloads sind leer in der vm leer. von mir heruntergeladene oder erzeugte dateien umfassen derzeit <10mb.
im übrigen sammelt sich ohnehin kaum was von mir in der vm, wird immer gleich alles auf windows übertragen.

bei .cache sieht's gegenwärtig so aus:

197 Objekte der Gesamtgröße 39,0 MB
(einige Inhalte unleserlich)

und welches der beiden genannten tools beobab oder filelight verbraucht weniger platz auf der platte?
ich müsste beide erst installieren, daher würde ich mich gerne für die sparsamere variante entscheiden.

[Lookbehind]

Hm, Nachtigal ick hör dir trapsen.

Also zunächst mal, könntest du den Befehl für /var/log mal so anpassen:

sudo find /var/log -type f -atime +365 -exec du -h {} \;

Das sorgt zum einen dafür, dass die Fehlermeldungen mit "Keine Berechtigungen" verschwinden, und zum anderen sehen wir auch wie groß die einzelnen Dateien sind.

Zum anderen, sehe ich da Log-Files von timeshift und muss spontan an frühe Fehlkonfigurationen auf btrfs denken. Du hast nicht zufällig btrfs im Einsatz? Das findest du z.B. mit den Befehl lsblk -f raus.

$ lsblk -f
NAME FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINT
sda                                                                         
└─sda1
     btrfs        data  a04f2d6b-428c-4b71-969b-e5fda8fb858c  239,4G    74% /home
sr0                                                                         
nvme0n1
│                                                                           
├─nvme0n1p1
│    btrfs        system
│                       f08c332e-80c4-4eb4-a2d7-284f35586661    5,3G    77% /
├─nvme0n1p2
│    swap   1           04bc2349-2456-40df-a09f-5e37baf7ee4b                [SWAP]
└─nvme0n1p3

Nein, btrfs ist nicht grundsätzlich schlecht. Wie man sieht, benutze ich es selbst, unter anderem weil es ein paar nette Funktionen mit bringt. Aber ich entsinne mich, dass es da früher mal Backup-Tools gab (und ich meine das war Timeshift), welches Snapshots erstellt und dann hinter sich nicht aufgeräumt hat. Dann läuft die Platte natürlich irgendwann voll. (Und dann ist es sogar erstaunlich, dass das so lange gehalten hat.)

Wenn da btrfs zum Einsatz kommt, und du wissen möchtest ob und welche Snapshots da drauf liegen geht das mit so einem Befehl:

$ sudo btrfs subvol list /

Wobei / natürlich durch den Mountpoint (z.B. in lsblk zu sehen) zu ersetzen ist.

Wobei 20GB für ein Desktop-System, welches auch wirklich benutzt wird, jetzt auch nicht SO viel sind.

$ df -lh /
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/nvme0n1p1   28G     22G  5,4G   81% /

[honx]

ja, das sudo hätte ich spätestens beim delete davor gesetzt, wegen root-rechten.
so gross sind gelistete dateien jedoch nicht (summe <10mb) fällt kaum ins gewicht:

8,0K /var/log/timeshift/2018-09-14_00-20-54_gui.log
16K /var/log/timeshift/2018-08-13_20-03-19_gui.log
12K /var/log/tallylog
4,0K /var/log/ubuntu-system-adjustments-adjust-grub-title.log
4,0K /var/log/ubuntu-system-adjustments-stop.log
8,0K /var/log/fontconfig.log
8,0K /var/log/dpkg.log.12.gz
4,0K /var/log/mintsystem.log
64K /var/log/bootstrap.log
8,0K /var/log/apt/term.log.12.gz
4,0K /var/log/apport.log.7.gz
4,0K /var/log/ubuntu-system-adjustments-start.log
4,0K /var/log/apport.log.5.gz
4,0K /var/log/apport.log.6.gz
4,0K /var/log/gpu-manager.log
4,0K /var/log/alternatives.log.12.gz
6,2M /var/log/boot.log
4,0K /var/log/installer/media-info
76K /var/log/installer/partman
216K /var/log/installer/syslog
4,0K /var/log/installer/casper.log
8,0K /var/log/installer/debug
556K /var/log/installer/initial-status.gz
4,0K /var/log/installer/version

lsblk -f zeigt in meinem fall leider keinen verbrauch an, das ist dessen ausgabe bei mir:

NAME   FSTYPE LABEL UUID                                 MOUNTPOINT
sda                                                      
└─sda1 ext4         5b26efa1-3b1e-4f78-8b33-6a995bf79037 /
sr0

btrfs sagt mir persönlich gar nichts, wenn damit mal was damit passiert ist, dann wohl automatisch.
sprich damals beim aufsetzen der linux mint vm im august 2018. ich persönlich habs nie angefasst.
ich schätze jedoch, das kommt eher nicht zum einsatz, denn "sudo btrfs subvol list /" gibt nur error:

ERROR: not a btrfs filesystem: /
ERROR: can't access '/'

Wobei 20GB für ein Desktop-System, welches auch wirklich benutzt wird, jetzt auch nicht SO viel sind.

wie gesagt, mein virtuelles disk image ist bei mir gegenwärtig nur 20gb gross.
in dem zusammenhang könnten 20gb verbrauch schon zum problem werden.
hab da so horrorstories gelesen, dass linux nicht mehr bootet, wenn platte voll.
"df -lh /" bei mir:

Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/sda1        20G     18G  880M   96% /

[Lookbehind]

ja, das sudo hätte ich spätestens beim delete davor gesetzt, wegen root-rechten.
so gross sind gelistete dateien jedoch nicht (summe <10mb) fällt kaum ins gewicht:

Ja, das dachte ich mir nämlich schon.

lsblk -f zeigt in meinem fall leider keinen verbrauch an, das ist dessen ausgabe bei mir:

NAME   FSTYPE LABEL UUID                                 MOUNTPOINT
sda                                                      
└─sda1 ext4         5b26efa1-3b1e-4f78-8b33-6a995bf79037 /
sr0

btrfs sagt mir persönlich gar nichts, wenn damit mal was damit passiert ist, dann wohl automatisch.
sprich damals beim aufsetzen der linux mint vm im august 2018. ich persönlich habs nie angefasst.
ich schätze jedoch, das kommt eher nicht zum einsatz, denn "sudo btrfs subvol list /" gibt nur error:

ERROR: not a btrfs filesystem: /
ERROR: can't access '/'

Naja, der lsblk-Befehl war auch weniger um zu gucken wieviel noch frei ist, sondern eher um zu sehen, welches Dateisystem zum Einsatz kommt. Und das ist, wie du schon richtig vermutet hast, kein btrfs, sondern ein klassisches ext4. Meine Therorie mit den Snapshots ist also hinfällig.

wie gesagt, mein virtuelles disk image ist bei mir gegenwärtig nur 20gb gross.
in dem zusammenhang könnten 20gb verbrauch schon zum problem werden.

Naja, wie gesagt, ein Desktop-Linux, das auch benutzt wird, kann halt gerne mal auf 20GB anwachsen, ohne große Probleme. Daher ist eine 20GB Platte schon eher klein. Ja, Linux kann auch mit deutlich weniger Platz auskommen, aber dann muss man sich auch entsprechend Mühe dabei geben und gegebenenfalls hier und da auf ein wenig Komfort verzichten. Festplatten sind heute nicht mehr SO teuer, von daher hätte ich da einfach n größeres Volume von gemacht.

hab da so horrorstories gelesen, dass linux nicht mehr bootet, wenn platte voll.
"df -lh /" bei mir:

Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/sda1        20G     18G  880M   96% /

Kein Spaß left on device

[honx]

Naja, wie gesagt, ein Desktop-Linux, das auch benutzt wird, kann halt gerne mal auf 20GB anwachsen, ohne große Probleme. Daher ist eine 20GB Platte schon eher klein. Ja, Linux kann auch mit deutlich weniger Platz auskommen, aber dann muss man sich auch entsprechend Mühe dabei geben und gegebenenfalls hier und da auf ein wenig Komfort verzichten. Festplatten sind heute nicht mehr SO teuer, von daher hätte ich da einfach n größeres Volume von gemacht.

ja, da hab ich mich leider an jene besagten "empfohlenen" 20gb gehalten. auch heute werden nach wie vor 20gb für linux mint empfohlen (15gb minimum):

Systemanforderungen:

• 32-Bit PAE-fähiger x86-Prozessor oder 64-Bit x86-Prozessor (Linux Mint 64-Bit benötigt ein 64-Bit-Prozessor. Linux Mint 32-Bit funktioniert sowohl auf 32-Bit PAE-fähigen Prozessoren und 64-Bit-Prozessoren)
• 1 GB RAM (2 GB empfohlen für eine komfortable Nutzung)
• 15 GB Speicherplatz (20 GB empfohlen)
• Grafikkarte mit einer Auflösung von 1024×768 Pixel (Bei niedrigeren Auflösungen: Man kann Fenster mit Alt + gedrückter linker Maustaste beliebig verschieben)
• DVD-ROM-Laufwerk oder USB-Anschluss

das ist folglich bullshit, was da empfohlen wird; hätte ich mich damals fürs minimum (15gb) entschieden, dann wär heute das system wohl längst am arsch...

[foobar]

thx, welche anleitung würdest du empfehlen bzgl. vergrösserung? ich finde auf anhieb mehrere.

Es geht über VBoxManage auf der Kommandozeile, aber sofern du bereits VirtualBox 6.x einsetzt, kannst du einfach den „Manager für virtuelle Medien” im Datei-Menü aufrufen. Da wählst du deine virtuelle Platte aus und kannst sie mit dem Schieberegeler vergrößern.

Im Prinzip kannst du VDIs auch ruhig richtig groß machen, die werden auf unterstützten Dateisystemen (wozu NTFS gehören dürfte) als sogenannte „Sparse Files” angelegt. Sprich, es wird nur belegter Platz wirklich alloziert. Du kannst eine 2 TB VDI anlegen, und die belegt nur 20GB auf dem Host, wenn auch nur 20GB in der VDI belegt sind. Prüfen kannst du das im Medienmanager im Info-Tab. Steht da „Art der Abspeicherung: dynamisch belegt”, dann schlag ruhig zu. Bei dynamischer Belegung ist das mehr so als obere Grenze zu verstehen, auf die die VDI maximal anwachsen kann.

[honx]

dann werd ich das morgen mal versuchen, nachdem ich vorsichtshalber eine kopie der linuxmint.vdi gemacht hab.
also, wenn ich die grösse auf sagen wir 40gb vergrössern will, dann müsste der befehl wohl wie folgt lauten:

"C:\Programme\Oracle\VirtualBox\VBoxManage.exe" modifyhd "C:\Users\honx\VirtualBox VMs\linuxmint.vdi" --resize 40960

vorausgesetzt, das wird im befehl wirklich in mb angegeben...
nicht dass ich das ding am ende noch kleiner und damit kaputt mache!

von version 6 musste ich leider ein rollback auf version 5.x machen, 6.x lief bei mir nicht.
linux z.b. lief damit grottenlangsam und brauchte auch mehrere minuten zum hochfahren.
und meine retro windows98 vm liess sich damit überhaupt nicht starten.
die zweite (offenbar simplere) lösung im manager kann ich folglich leider nicht anwenden.

//edit: ich musste den post nun in windows editieren.
denn im firefox unter linux mint machte es jetzt ganz plötzlich keine zeilenumbrüche mehr.
text war nach dem speichern nur noch eine einzige durchgehende wurst. sah etwa so aus:

Spoiler:(zum lesen bitte Text markieren)

dann werd ich das morgen mal versuchen, nachdem ich vorsichtshalber eine kopie der linuxmint.vdi gemacht hab. [Bild: s_004.gif] also, wenn ich die grösse auf sagen wir 40gb vergrössern will, dann müsste der befehl wohl wie folgt lauten:

"C:\Programme\Oracle\VirtualBox\VBoxManage.exe" modifyhd  "C:\Users\honx\VirtualBox VMs\linuxmint.vdi" --resize 40960

vorausgesetzt, das wird im befehl wirklich in mb angegeben... nicht dass ich das ding am ende noch kleiner und damit kaputt mache! [Bild: s_004.gif] von version 6 musste ich leider ein rollback auf version 5.x machen, 6.x lief bei mir nicht. linux z.b. lief damit grottenlangsam und brauchte auch mehrere minuten zum hochfahren. und meine retro windows98 vm liess sich damit überhaupt nicht starten. die zweite (offenbar simplere) lösung im manager kann ich folglich leider nicht anwenden.

keine umbrüche oder leerzeilen. keine ahnung, was da nun wieder nicht stimmt.
muss wohl mal diese linux vm neustarten, schätze ich.

[honx]

hab jetzt die grösse der .vdi auf 30gb erhöht, doch in der vm hat sich nichts geändert. da sind immer noch 800mb frei.
muss ich innerhalb von linux noch irgendwas machen, damit das funktioniert? denn das müssten ja nun +10gb sein...

Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/sda1        20G     18G  866M   96% /

//edit: nach dem neu hochfahren funktionieren im forum nun auch zeilenumbrüche wieder. keine ahnung, was das war.

[Lookbehind]

hab jetzt die grösse der .vdi auf 30gb erhöht, doch in der vm hat sich nichts geändert. da sind immer noch 800mb frei.
muss ich innerhalb von linux noch irgendwas machen, damit das funktioniert? denn das müssten ja nun +10gb sein...

Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/sda1        20G     18G  866M   96% /

//edit: nach dem neu hochfahren funktionieren im forum nun auch zeilenumbrüche wieder. keine ahnung, was das war.

Die Platte hat sich vergrößert, nicht aber die Partition, und auch nicht das Dateisystem.

Ich bin mir gerade nicht sicher, wie Linux reagiert, wenn man die Parition, von der es läuft verändert. Ich könnte mir vorstellen, dass das funktioniert, bin mir aber nicht ganz sicher. Ich hab das nie mit normalen Partitionen gemacht, sondern immer mit nem LVM oder ähnlichen Systemen, die darauf ausgelegt sind.

Das Dateisystem (ext4) lässt sich im laufenden Betrieb vergrößern, das hab ich auch schon ein paar mal gemacht. Allerdings dauert das EWIG wenn man es im laufenden Betrieb macht.

Ich empfehle ein Live-System (z.B. die ISO von der installiert wurde) zu starten und dort ein Tool wie gParted (die grafische Version von parted) zu booten um Partition und Dateisystem zu vergrößern.

[honx]

stimmt, logisch! paritioniert muss das dingens auch ja noch werden! da hab ich überhaupt nicht dran gedacht!
hab ich eben erledigt, mit linuxmint dvd image gebootet, mit gparted partition vergrössert, nun sieht's so aus:

Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/sda1        30G     18G   11G   64% /

hab danach zweimal meine vm gebootet. um sicherzugehen, dass es funktioniert und partition nicht kaputt ist.
anschliessend hab ich meine zur sicherheit angelegte kopie der vm wieder gelöscht, waren ja 20gb verbraucht.

nun, mit 10,9gb freiem speicher sollte ich mich nun wohl eine weile über wasser halten können.

[honx]

gut, dass ich das image nur auf 30gb vergrössert hab, nicht auf 40gb. das ding wächst ganz ordentlich.
gestern waren es noch 19.7gb, heute bringt jenes image bereits 21.8gb auf die waage.
hab seit gestern allerdings nur 200mb runtergeladen, nicht 2gb (das zehnfache davon).
und jene 200mb sind auch schon wieder verschoben nehmen innerhalb der vm keinen platz mehr in anspruch.
dort bin ich wieder auf 10.9gb freiem speicherplatz wie gestern abend und dennoch ist das image so gross...

[foobar]

Man kann eine VDI (wenn sie als Sparse File angelegt wurde) auch wieder verkleinern, also freigeräumten Speicherplatz wieder freigeben. Dazu in der VDI die leeren Bereiche ausnullen, unter Linux bspw. als root mit:

# cat /dev/zero > nullfile.bin; rm nullfile.bin

Dabei kann die VDI vorübergehend größer werden. Dann im Windows-Host:

> VBoxManage.exe modifymedium --compact c:\pfad\zur\datei.vdi

Der Nachteil hier ist, dass man das immer von Hand machen muss.



Alternativ kann man ATA-Trim benutzen. Das wird normalerweise verwendet, um einer SSD mitzuteilen, welche Sektoren nicht mehr gebraucht werden und wieder für’s Wear Leveling zur Verfügung stehen. Aber auch VirtualBox kann es auswerten, um Sektoren, die in der VDI nicht mehr belegt sind, dann auch im Host-Dateisysytem freizugeben. Allerdings das muss freigeschaltet worden sein, ansonsten geht es nicht. Ob Trim unterstützt wird, kann man als root in der Linux-VM mit hdparm ermitteln:

# hdparm -I /dev/sda | grep TRIM
	   *	Data Set Management TRIM supported (limit unknown)

In dem o.g. Fall wird Trim unterstützt. Kommt keine Ausgabe oder steht da „unsupportet”, dann nicht.


Um es nachträglich zu aktivieren, muss man die VDI vorübergehend von der (ausgeschalteten) VM ablösen und dann mit:

> VBoxManage storageattach "Name der VM" --storagectl "SATA" --port 0 --device 0 --nonrotational on --discard on --medium "C:\pfad\zur\datei.vdi" --type hdd

neu in die VM einhängen (ich gehe mal davon aus, dass die VDI per SATA eingebunden wird). Anschließend kann man (wieder als root):

# fstrim -v /

in der VM ausführen.

Der Trim kann (gerade beim ersten Mal) eine Weile dauern. Aber danach sollte die VDI entsprechend geschrumpft sein. In meiner Test-VM mit Linux beispielsweise von ursprünglich 31.258.050.560 Bytes auf 11.048.845.312 Bytes (also fast 19 GB gespart).

Die meisten modernen Linux-Distris können via Cronjob bzw. SystemD-Timer auch automatisch trimmen (i.d.R. einmal die Woche). Der sollte also in Zukunft regelmäßig aufräumen. Das ist der Vorteil der Trim-Methode. Einmal eingerichtet, sollte sie automatisch laufen. Testen, ob der Timer aktiv ist, kannst du unter Mint mit:

# systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
     Loaded: loaded (/lib/systemd/system/fstrim.timer; enabled; vendor preset: >
     Active: active (waiting) since Sun 2020-11-08 14:12:38 CET; 1min 11s ago
    Trigger: Mon 2020-11-09 00:00:00 CET; 9h left
   Triggers: ● fstrim.service
       Docs: man:fstrim

Nov 08 14:12:38 mintbuild systemd[1]: Started Discard unused blocks once a week.

[honx]

Ob Trim unterstützt wird, kann man als root in der Linux-VM mit hdparm ermitteln:

# hdparm -I /dev/sda | grep TRIM
       *    Data Set Management TRIM supported (limit unknown)

In dem o.g. Fall wird Trim unterstützt. Kommt keine Ausgabe oder steht da „unsupportet”, dann nicht.

damit bekomm ich leider keine ausgabe. gar nichts. nicht einmal "unsupported" oder irgendeinen error.
ich kann wohl davon ausgehen, dass trim bei mir nicht unterstützt wird. bleibt also nur erste option.
bevor ich das mache, werd ich allerdings erst eine weile beobachten, wie es sich mit der grösse verhält.
mal sehen, ob und wie weit das image weiter wächst (gegenwärtig 22,0gb).

[foobar]

damit bekomm ich leider keine ausgabe. gar nichts. nicht einmal "unsupported" oder irgendeinen error.

Das ist normal, wenn es nicht unterstützt wird.

ich kann wohl davon ausgehen, dass trim bei mir nicht unterstützt wird. bleibt also nur erste option.

Ähm... nein. Dann folgst du meinem restlichen Post, in dem ich mir die Mühe mache, dir Schritt für Schritt zu erklären, wie du den Trim-Support in der VM einschaltest.

[honx]

achso, das hab ich nicht richtig ganz kapiert oder schlicht falsch gelesen.
ich dachte nämlich der zweite weg wäre nur zu machen, wenn unterstützt.
da dafür wieder ein vorheriges backup besagter virtuellen maschine fällig ist,
welches ewig dauert, werd ich allerdings erst am wochenende dazukommen.

[honx]

da das image inzwischen auf 22,8gb angewachsen ist, ohne irgendwelche grossartigen aktionen in der vm (keine downloads oder sonstiges, lediglich ein kernel-update), konnte ich nicht bis zum wochenende warten und hab nun deinen vorschlag gestartet. sprich, ich hab das image entfernt und mit deinem befehl in der kommandozeile neu eingefügt, danach die vm gestartet und nochmal hdparm gestartet.
nun stand bei mir auch "* Data Set Management TRIM supported (limit unknown)", also weiter mit "fstrim -v /" und das läuft jetzt schon ne weile (zumindest hoffe ich, dass es läuft). gibts denn da keinerlei status- oder aktivitätsanzeige? im terminal hab ich lediglich den befehl "sudo fstrim -v /" stehen und den cursor in der nächsten zeile. sonst gar nix? woher weiss ich, ob das ding tatsächlich arbeitet und sich nicht aufgehängt hat?

wie dem auch sei... da um solche zeit ohnehin keiner mehr online ist, werd ich jetzt mal ins horizontale gehen und meine vm einfach laufen lassen... werd dann in der früh ja sehen, ob sich hier irgendwas getan hat...

[foobar]

gibts denn da keinerlei status- oder aktivitätsanzeige?

Nope. Ist ein klassisches Unix-Programm. Wenn es nix zu melden hat, hält es die Fresse und belästigt die User nicht. Normalerweise läuft es einfach durch und erzeugt gar keine Ausgabe, wenn alles geklappt hat. Aber über das „-v” haben wir festgelegt, dass es am Ende wenigstens eine kleine Statuszeile ausgibt. Da steht dann sowas wie: „/: 47.11 MiB (42096 bytes) trimmed”.

[honx]

ja, ist inzwischen durchgelaufen, mint image hat jetzt wieder 19,7gb wie vor der vergrösserung.
was mich allerdings etwas wundert ist angegebene "grösse", welche angeblich getrimmt wurde.
da war etwas von 11,?gb die rede, das image ist allerdings "nur" um etwa 4gb geschrumpft...

hab allerdings vergessen, "systemctl status fstrim.timer" auszuführen, ob der cronjob auch läuft.
das muss ich später nachholen, wenn ich wieder zuhause bin.