On Sun, Apr 26, 2020 at 12:15 PM <tu...@posteo.de> wrote:
>
> On 04/26 11:20, Rich Freeman wrote:
> > On Sun, Apr 26, 2020 at 10:52 AM <tu...@posteo.de> wrote:
> > >
> > > Fstrim reports about 200 GiB of trimmed data.
> > >
> >
> > My suggestion would be to run fstrim twice in a row and see how fast
> > it operates and what the results are. If the second one completes
> > very quickly that suggests that the drive is sane. I'd probably just
> > run it daily in that case, but weekly is probably fine especially if
> > the drive isn't very full.
> >
>
> host:/root>fstrim -v /
> /: 3.3 GiB (3578650624 bytes) trimmed
> host:/root>fstrim -v /
> /: 0 B (0 bytes) trimmed
>
> This time the first fstrim reports a small mount of trimmed
> data and second one no fstrimmed data at all.
>
Ok, I became a bit less lazy and started looking at the source.
All fstrim does is send an FITRIM ioctl to the kernel for the device.
This is implemented in a filesystem-dependent manner, and I couldn't
actually find any documentation on it (actual documentation on the
ioctl - not the fstrim manpage/etc). A quick glimpse at the ext4
source suggests that ext4 has a flag that can track whether a group of
blocks has been trimmed yet or not since it was last deallocated. So
ext4 will make repeated fstrim runs a no-op and the drive won't see
these.
At least, that was what I got after about 5-10min of browsing. I
didn't take the time to grok how ext4 tracks free space and so on.
Incidentally, in the other thread the reason that dry-run didn't
report anything to be trimmed is that this is hard-coded:
printf(_("%s: 0 B (dry run) trimmed on %s\n"), path, devname);
https://github.com/karelzak/util-linux/blob/master/sys-utils/fstrim.c#L109
Otherwise the ioctl returns how much space was trimmed, and fstrim outputs this.
--
Rich
