On Sun, 26 Apr 2020 18:15:51 +0200 tu...@posteo.de wrote: > Filesystem Size Used Avail Use% Mounted on > /dev/root 246G 45G 189G 20% /
Given that (Size - Used) is roughly 200G, it suggests to me that perhaps, some process somewhere is creating and deleting a lot of temporary files on this device (or maybe simply re-writing the same file multiple times) From a userspace, this would be invisible, as the "new" file would be in a new location on the disk, and the "old" file would be invisible, and marked "can be overwritten". So if you did: for i in {0..200}; do cp a b rm a mv b a done Where "a" is a 1G file, I'd expect this to have a *ceiling* of 200G that would turn up in fstrim output, as once you reached iteration 201, where "can overwrite" would allow the SSD to go back and rewrite over the space used in iteration 1. While the whole time, the visible disk usage in df -h would never exceed 46G . I don't know if this is what is happening, I don't have an SSD and don't get to use fstrim. But based on what you've said, the results aren't *too* surprising. Though its possible the hardware has some internal magic to elide some writes, potentially making the "cp" action incur very few writes, which would show up in the smartctl data, but ext4 might not know anything about that, so perhaps fstrim only indicates what ext4 *tracked* as being cleaned, while it may have incurred much less cleanup required on the hardware. That would explain the difference between smartctl and fstrim results. Maybe compare smartctl output over time with /sys/fs/ext4/<device>/session_write_kbytes and see if one grows faster than the other? :) My local session_write_kbytes is currently at 709G, the partition its for is only 552G, with 49G space, and its been booted 33 days, so "21G of writes a day". And uh, lifetime_write_kbytes is about 18TB. Yikes. ( compiling things involves a *LOT* of ephemeral data ) Also, probably don't assume the amount of free space on your partition is all the physical device has at its disposal to use. It seems possible that on the hardware, the total pool of "free blocks" is arbitrarily usable by the device for wear levelling, and a TRIM command to that device could plausibly report more blocks trimmed than your current partition size, depending on how its implemented. But indeed, lots of speculation here on my part :)
pgpG5i84QkMfE.pgp
Description: OpenPGP digital signature