Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #71932 > unrolled thread

Bug#909473: fstrim shows incorrect trimmed size after reboot

Started bySalvatore Bonaccorso <carnil@debian.org>
First post2021-05-28 21:40 +0200
Last post2021-06-09 00:00 +0200
Articles 7 — 4 participants

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#909473: fstrim shows incorrect trimmed size after reboot Salvatore Bonaccorso <carnil@debian.org> - 2021-05-28 21:40 +0200
    Processed: Re: Bug#909473: fstrim shows incorrect trimmed size  after reboot "Debian Bug Tracking System" <owner@bugs.debian.org> - 2021-05-28 21:40 +0200
    Bug#909473: fstrim shows incorrect trimmed size after reboot Laurent Bigonville <bigon@debian.org> - 2021-06-08 16:00 +0200
      Processed: Re: Bug#909473: fstrim shows incorrect trimmed size  after reboot "Debian Bug Tracking System" <owner@bugs.debian.org> - 2021-06-08 16:00 +0200
      Bug#909473: fstrim shows incorrect trimmed size after reboot Bastian Blank <waldi@debian.org> - 2021-06-08 21:50 +0200
        Bug#909473: fstrim shows incorrect trimmed size after reboot Laurent Bigonville <bigon@debian.org> - 2021-06-08 23:50 +0200
          Bug#909473: fstrim shows incorrect trimmed size after reboot Bastian Blank <waldi@debian.org> - 2021-06-09 00:00 +0200

#71932 — Bug#909473: fstrim shows incorrect trimmed size after reboot

FromSalvatore Bonaccorso <carnil@debian.org>
Date2021-05-28 21:40 +0200
SubjectBug#909473: fstrim shows incorrect trimmed size after reboot
Message-ID<CjQuR-7w-1@gated-at.bofh.it>
Control: tags -1 + moreinfo

Hi Laurent,

On Mon, Sep 24, 2018 at 01:37:01PM +0200, Laurent Bigonville wrote:
> Package: src:linux
> Version: 4.18.8-1
> Severity: normal
> 
> Hi,
> 
> Not sure who to blame here, but when running fstrim -va it show the size
> of the disk it has trimmed, if I'm running fstrim again it shows 0 for
> all the disk.
> 
> If I reboot, and then run fstrim again it shows (almost) the same value
> as the 1st time. All the disks have the discard option enabled, all fs
> are ext4, except /boot which is ext2/
> 
> See the logs:
> 
> bigon@valinor:~$ journalctl -u fstrim.service
> -- Logs begin at Sat 2018-09-08 12:48:02 CEST, end at Mon 2018-09-24 13:32:05 CEST. --
> sep 17 10:44:21 valinor systemd[1]: Starting Discard unused blocks...
> sep 17 10:44:51 valinor fstrim[11186]: /var/cache/apt-cacher-ng : 930,1 MiB (975245312 octets) taillés
> sep 17 10:44:51 valinor fstrim[11186]: /var/lib/sbuild/build : 9,8 GiB (10463989760 octets) taillés
> sep 17 10:44:51 valinor fstrim[11186]: /var/lib/libvirt : 17,9 GiB (19241095168 octets) taillés
> sep 17 10:44:51 valinor fstrim[11186]: /var/lib/docker : 10 GiB (10713788416 octets) taillés
> sep 17 10:44:51 valinor fstrim[11186]: /var/lib/flatpak : 1,4 GiB (1496272896 octets) taillés
> sep 17 10:44:51 valinor fstrim[11186]: /home : 11,3 GiB (12105969664 octets) taillés
> sep 17 10:44:51 valinor fstrim[11186]: /boot : 126,9 MiB (133014528 octets) taillés
> sep 17 10:44:51 valinor fstrim[11186]: / : 8,6 GiB (9217847296 octets) taillés
> sep 17 10:44:51 valinor systemd[1]: Started Discard unused blocks.
> -- Reboot --
> sep 24 10:12:35 valinor systemd[1]: Starting Discard unused blocks...
> sep 24 10:13:08 valinor fstrim[26936]: /var/lib/sbuild/build : 9,8 GiB (10455736320 octets) taillés
> sep 24 10:13:08 valinor fstrim[26936]: /var/cache/apt-cacher-ng : 922,8 MiB (967565312 octets) taillés
> sep 24 10:13:08 valinor fstrim[26936]: /var/lib/libvirt : 17,9 GiB (19241095168 octets) taillés
> sep 24 10:13:08 valinor fstrim[26936]: /var/lib/docker : 11,4 GiB (12180299776 octets) taillés
> sep 24 10:13:08 valinor fstrim[26936]: /var/lib/flatpak : 1,4 GiB (1496272896 octets) taillés
> sep 24 10:13:08 valinor fstrim[26936]: /home : 11 GiB (11825807360 octets) taillés
> sep 24 10:13:08 valinor fstrim[26936]: /boot : 126,9 MiB (133008384 octets) taillés
> sep 24 10:13:08 valinor fstrim[26936]: / : 8,6 GiB (9219850240 octets) taillés
> sep 24 10:13:08 valinor systemd[1]: Started Discard unused blocks.
> -- Reboot --
> sep 24 13:20:54 valinor systemd[1]: Starting Discard unused blocks...
> sep 24 13:21:28 valinor fstrim[6751]: /var/lib/docker : 11,4 GiB (12181008384 octets) taillés
> sep 24 13:21:28 valinor fstrim[6751]: /var/cache/apt-cacher-ng : 793,9 MiB (832487424 octets) taillés
> sep 24 13:21:28 valinor fstrim[6751]: /var/lib/libvirt : 17,9 GiB (19241095168 octets) taillés
> sep 24 13:21:28 valinor fstrim[6751]: /home : 10,8 GiB (11617431552 octets) taillés
> sep 24 13:21:28 valinor fstrim[6751]: /var/lib/sbuild/build : 9,8 GiB (10463989760 octets) taillés
> sep 24 13:21:28 valinor fstrim[6751]: /var/lib/flatpak : 1,4 GiB (1496272896 octets) taillés
> sep 24 13:21:28 valinor fstrim[6751]: /boot : 126,9 MiB (133008384 octets) taillés
> sep 24 13:21:28 valinor fstrim[6751]: / : 8,6 GiB (9211752448 octets) taillés
> sep 24 13:21:28 valinor systemd[1]: Started Discard unused blocks.
> sep 24 13:32:05 valinor systemd[1]: Starting Discard unused blocks...
> sep 24 13:32:05 valinor fstrim[7323]: /var/lib/docker : 0 B (0 octets) taillés
> sep 24 13:32:05 valinor fstrim[7323]: /var/cache/apt-cacher-ng : 0 B (0 octets) taillés
> sep 24 13:32:05 valinor fstrim[7323]: /var/lib/libvirt : 0 B (0 octets) taillés
> sep 24 13:32:05 valinor fstrim[7323]: /home : 0 B (0 octets) taillés
> sep 24 13:32:05 valinor fstrim[7323]: /var/lib/sbuild/build : 0 B (0 octets) taillés
> sep 24 13:32:05 valinor fstrim[7323]: /var/lib/flatpak : 0 B (0 octets) taillés
> sep 24 13:32:05 valinor fstrim[7323]: /boot : 0 B (0 octets) taillés
> sep 24 13:32:05 valinor fstrim[7323]: / : 0 B (0 octets) taillés
> sep 24 13:32:05 valinor systemd[1]: Started Discard unused blocks.
> 
> There is definitely something boggus here

Is this still something you are able to reproduce this way with a
recent kernel?

Regards,
Salvatore

[toc] | [next] | [standalone]

#71933 — Processed: Re: Bug#909473: fstrim shows incorrect trimmed size after reboot

From"Debian Bug Tracking System" <owner@bugs.debian.org>
Date2021-05-28 21:40 +0200
SubjectProcessed: Re: Bug#909473: fstrim shows incorrect trimmed size after reboot
Message-ID<CjQuR-7w-9@gated-at.bofh.it>
In reply to#71932
Processing control commands:

> tags -1 + moreinfo
Bug #909473 [src:linux] fstrim shows incorrect trimmed size after reboot
Added tag(s) moreinfo.

-- 
909473: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909473
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#72141

FromLaurent Bigonville <bigon@debian.org>
Date2021-06-08 16:00 +0200
Message-ID<CnKqS-1Sy-5@gated-at.bofh.it>
In reply to#71932
Control: tags -1 - moreinfo

Le 28/05/21 à 21:28, Salvatore Bonaccorso a écrit :
> Control: tags -1 + moreinfo
>
> Hi Laurent,
>
> On Mon, Sep 24, 2018 at 01:37:01PM +0200, Laurent Bigonville wrote:
>> Package: src:linux
>> Version: 4.18.8-1
>> Severity: normal
>>
>> Hi,
>>
>> Not sure who to blame here, but when running fstrim -va it show the size
>> of the disk it has trimmed, if I'm running fstrim again it shows 0 for
>> all the disk.
>>
>> If I reboot, and then run fstrim again it shows (almost) the same value
>> as the 1st time. All the disks have the discard option enabled, all fs
>> are ext4, except /boot which is ext2/
>>
>> See the logs:
>>
>> bigon@valinor:~$ journalctl -u fstrim.service
>> -- Logs begin at Sat 2018-09-08 12:48:02 CEST, end at Mon 2018-09-24 13:32:05 CEST. --
>> sep 17 10:44:21 valinor systemd[1]: Starting Discard unused blocks...
>> sep 17 10:44:51 valinor fstrim[11186]: /var/cache/apt-cacher-ng : 930,1 MiB (975245312 octets) taillés
>> sep 17 10:44:51 valinor fstrim[11186]: /var/lib/sbuild/build : 9,8 GiB (10463989760 octets) taillés
>> sep 17 10:44:51 valinor fstrim[11186]: /var/lib/libvirt : 17,9 GiB (19241095168 octets) taillés
>> sep 17 10:44:51 valinor fstrim[11186]: /var/lib/docker : 10 GiB (10713788416 octets) taillés
>> sep 17 10:44:51 valinor fstrim[11186]: /var/lib/flatpak : 1,4 GiB (1496272896 octets) taillés
>> sep 17 10:44:51 valinor fstrim[11186]: /home : 11,3 GiB (12105969664 octets) taillés
>> sep 17 10:44:51 valinor fstrim[11186]: /boot : 126,9 MiB (133014528 octets) taillés
>> sep 17 10:44:51 valinor fstrim[11186]: / : 8,6 GiB (9217847296 octets) taillés
>> sep 17 10:44:51 valinor systemd[1]: Started Discard unused blocks.
>> -- Reboot --
>> sep 24 10:12:35 valinor systemd[1]: Starting Discard unused blocks...
>> sep 24 10:13:08 valinor fstrim[26936]: /var/lib/sbuild/build : 9,8 GiB (10455736320 octets) taillés
>> sep 24 10:13:08 valinor fstrim[26936]: /var/cache/apt-cacher-ng : 922,8 MiB (967565312 octets) taillés
>> sep 24 10:13:08 valinor fstrim[26936]: /var/lib/libvirt : 17,9 GiB (19241095168 octets) taillés
>> sep 24 10:13:08 valinor fstrim[26936]: /var/lib/docker : 11,4 GiB (12180299776 octets) taillés
>> sep 24 10:13:08 valinor fstrim[26936]: /var/lib/flatpak : 1,4 GiB (1496272896 octets) taillés
>> sep 24 10:13:08 valinor fstrim[26936]: /home : 11 GiB (11825807360 octets) taillés
>> sep 24 10:13:08 valinor fstrim[26936]: /boot : 126,9 MiB (133008384 octets) taillés
>> sep 24 10:13:08 valinor fstrim[26936]: / : 8,6 GiB (9219850240 octets) taillés
>> sep 24 10:13:08 valinor systemd[1]: Started Discard unused blocks.
>> -- Reboot --
>> sep 24 13:20:54 valinor systemd[1]: Starting Discard unused blocks...
>> sep 24 13:21:28 valinor fstrim[6751]: /var/lib/docker : 11,4 GiB (12181008384 octets) taillés
>> sep 24 13:21:28 valinor fstrim[6751]: /var/cache/apt-cacher-ng : 793,9 MiB (832487424 octets) taillés
>> sep 24 13:21:28 valinor fstrim[6751]: /var/lib/libvirt : 17,9 GiB (19241095168 octets) taillés
>> sep 24 13:21:28 valinor fstrim[6751]: /home : 10,8 GiB (11617431552 octets) taillés
>> sep 24 13:21:28 valinor fstrim[6751]: /var/lib/sbuild/build : 9,8 GiB (10463989760 octets) taillés
>> sep 24 13:21:28 valinor fstrim[6751]: /var/lib/flatpak : 1,4 GiB (1496272896 octets) taillés
>> sep 24 13:21:28 valinor fstrim[6751]: /boot : 126,9 MiB (133008384 octets) taillés
>> sep 24 13:21:28 valinor fstrim[6751]: / : 8,6 GiB (9211752448 octets) taillés
>> sep 24 13:21:28 valinor systemd[1]: Started Discard unused blocks.
>> sep 24 13:32:05 valinor systemd[1]: Starting Discard unused blocks...
>> sep 24 13:32:05 valinor fstrim[7323]: /var/lib/docker : 0 B (0 octets) taillés
>> sep 24 13:32:05 valinor fstrim[7323]: /var/cache/apt-cacher-ng : 0 B (0 octets) taillés
>> sep 24 13:32:05 valinor fstrim[7323]: /var/lib/libvirt : 0 B (0 octets) taillés
>> sep 24 13:32:05 valinor fstrim[7323]: /home : 0 B (0 octets) taillés
>> sep 24 13:32:05 valinor fstrim[7323]: /var/lib/sbuild/build : 0 B (0 octets) taillés
>> sep 24 13:32:05 valinor fstrim[7323]: /var/lib/flatpak : 0 B (0 octets) taillés
>> sep 24 13:32:05 valinor fstrim[7323]: /boot : 0 B (0 octets) taillés
>> sep 24 13:32:05 valinor fstrim[7323]: / : 0 B (0 octets) taillés
>> sep 24 13:32:05 valinor systemd[1]: Started Discard unused blocks.
>>
>> There is definitely something boggus here
> Is this still something you are able to reproduce this way with a
> recent kernel?

Hello Salvatore,

Yes, just tested it now and  it's still happening with the kernel 
currently in unstable (5.10.40-1)

[toc] | [prev] | [next] | [standalone]

#72142 — Processed: Re: Bug#909473: fstrim shows incorrect trimmed size after reboot

From"Debian Bug Tracking System" <owner@bugs.debian.org>
Date2021-06-08 16:00 +0200
SubjectProcessed: Re: Bug#909473: fstrim shows incorrect trimmed size after reboot
Message-ID<CnKqS-1Sy-7@gated-at.bofh.it>
In reply to#72141
Processing control commands:

> tags -1 - moreinfo
Bug #909473 [src:linux] fstrim shows incorrect trimmed size after reboot
Removed tag(s) moreinfo.

-- 
909473: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909473
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#72146

FromBastian Blank <waldi@debian.org>
Date2021-06-08 21:50 +0200
Message-ID<CnPTB-5aE-29@gated-at.bofh.it>
In reply to#72141
Hi

On Tue, Jun 08, 2021 at 03:48:11PM +0200, Laurent Bigonville wrote:
> > > There is definitely something boggus here
> Yes, just tested it now and  it's still happening with the kernel currently
> in unstable (5.10.40-1)

Why do you think this numbers are wrong?  "fstrim" initially requests
discard of all unused blocks, so a large number.  But why should it do
the same on subsequent calls while it still knows what it did the last
time?

ext4 caches the information if a particular block group was trimmed, but
this information is not persistent.  (Using bit
EXT4_GROUP_INFO_WAS_TRIMMED_BIT in ext4_group_info.bb_state.)

Bastian

-- 
Live long and prosper.
		-- Spock, "Amok Time", stardate 3372.7

[toc] | [prev] | [next] | [standalone]

#72149

FromLaurent Bigonville <bigon@debian.org>
Date2021-06-08 23:50 +0200
Message-ID<CnRLH-6j9-1@gated-at.bofh.it>
In reply to#72146
Le 8/06/21 à 21:24, Bastian Blank a écrit :
> Hi
Hello,
> On Tue, Jun 08, 2021 at 03:48:11PM +0200, Laurent Bigonville wrote:
>>>> There is definitely something boggus here
>> Yes, just tested it now and  it's still happening with the kernel currently
>> in unstable (5.10.40-1)
> Why do you think this numbers are wrong?  "fstrim" initially requests
> discard of all unused blocks, so a large number.  But why should it do
> the same on subsequent calls while it still knows what it did the last
> time?
>
> ext4 caches the information if a particular block group was trimmed, but
> this information is not persistent.  (Using bit
> EXT4_GROUP_INFO_WAS_TRIMMED_BIT in ext4_group_info.bb_state.)

Well I would expect that if I'm running fstrim, the same blocks would 
not be trimmed again (even after reboot) if I'm running the command again

Here it seems that it's the case, the number of blocks that are being 
trimmed are the same after reboot.

Are the discard commands delayed and actually not executed when the 
command is run, or am I overlooking something?

[toc] | [prev] | [next] | [standalone]

#72150

FromBastian Blank <waldi@debian.org>
Date2021-06-09 00:00 +0200
Message-ID<CnRVn-6mg-5@gated-at.bofh.it>
In reply to#72149
Hi

On Tue, Jun 08, 2021 at 11:43:06PM +0200, Laurent Bigonville wrote:
> Well I would expect that if I'm running fstrim, the same blocks would not be
> trimmed again (even after reboot) if I'm running the command again

But how would it know that it was already trimmed?

> Here it seems that it's the case, the number of blocks that are being
> trimmed are the same after reboot.

Sure, you did not change the free space (much).

> Are the discard commands delayed and actually not executed when the command
> is run, or am I overlooking something?

You are overlooking that the information about discards is only in
memory.

Bastian

-- 
If some day we are defeated, well, war has its fortunes, good and bad.
		-- Commander Kor, "Errand of Mercy", stardate 3201.7

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web