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


Groups > linux.debian.user > #273231

Re: Unused blocks and fstrim

From Steve Keller <keller.steve@gmx.de>
Newsgroups linux.debian.user
Subject Re: Unused blocks and fstrim
Date 2024-09-23 15:30 +0200
Message-ID <JpRix-ei0s-3@gated-at.bofh.it> (permalink)
References <JoI7D-dAku-3@gated-at.bofh.it> <JoIKl-dANq-9@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


Tim Woodall <debianuser@woodall.me.uk> writes:

> In the default, iscsi, md, lvm, ext2 do not keep this information. Don't
> know if it's configurable sonewhere but I suspect not. Don't know about
> btrfs.
>
> Some of this data is cached, but not between reboots.

I have played a bit and it seems for ext4 and btrfs they keep
information on already trimmed blocks but only as long as the file
system is mounted:

    # lvcreate -n foo -L1G vg0
      Logical volume "foo" created.
    # mkfs.ext4 /dev/vg0/foo
    mke2fs 1.47.0 (5-Feb-2023)
    [...]
    # mount /dev/vg0/foo /mnt
    # fstrim -v /mnt
    /mnt: 973.4 MiB (1020678144 bytes) trimmed
    # fstrim -v /mnt
    /mnt: 0 B (0 bytes) trimmed
    # umount /mnt
    # mount /dev/vg0/foo /mnt
    # fstrim -v /mnt
    /mnt: 973.4 MiB (1020678144 bytes) trimmed
    # fstrim -v /mnt
    /mnt: 0 B (0 bytes) trimmed
    # umount /mnt
    # mkfs.btrfs -f /dev/vg0/foo
    btrfs-progs v6.2
    See http://btrfs.wiki.kernel.org for more information.

    Performing full device TRIM /dev/vg0/foo (1.00GiB) ...
    [...]
    # mount /dev/vg0/foo /mnt
    # fstrim -v /mnt
    /mnt: 1022.6 MiB (1072267264 bytes) trimmed
    # fstrim -v /mnt
    /mnt: 126 MiB (132087808 bytes) trimmed
    # fstrim -v /mnt
    /mnt: 126 MiB (132087808 bytes) trimmed
    # fstrim -v /mnt
    /mnt: 126 MiB (132087808 bytes) trimmed
    # umount /mnt
    # mount /dev/vg0/foo /mnt
    # fstrim -v /mnt
    /mnt: 1022.6 MiB (1072267264 bytes) trimmed
    # fstrim -v /mnt
    /mnt: 126 MiB (132087808 bytes) trimmed
    # fstrim -v /mnt
    /mnt: 126 MiB (132087808 bytes) trimmed
    # umount /mnt

I also currently play with ext4 and btrfs on QCOW2 with discard
support.  Looks nice.

> The raid rebuild is a particular pain point IMO. It's important to do a
> discard after a failed disk rebuild otherwise every block is 'in use' on
> the underlying storage.

Hmm, does a RAID rebuild really always copy the whole new disk, even
the unused space?  But what kind of info is then kept in the first
128 MiB of /dev/md0, if not a flag for every block telling whether it's
used or not?

> After a rebuild I always create a LV with all the free space and then
> discard it.

:(

I currently have RAID only on a server with HDDs which don't support
TRIM anyway.  I have only needed twice to rebuild the RAID-1 with 2
disks and I seem to remember that not the whole disk was copied, but I
might be wrong on that.

Steve

Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Unused blocks and fstrim Steve Keller <keller.steve@gmx.de> - 2024-09-20 11:30 +0200
  Re: Unused blocks and fstrim Tim Woodall <debianuser@woodall.me.uk> - 2024-09-20 12:10 +0200
    Re: Unused blocks and fstrim Michael Kjörling <c9bc136c6063@ewoof.net> - 2024-09-20 13:00 +0200
    Re: Unused blocks and fstrim Steve Keller <keller.steve@gmx.de> - 2024-09-23 15:30 +0200
      Re: Unused blocks and fstrim Tim Woodall <debianuser@woodall.me.uk> - 2024-09-23 16:40 +0200

csiph-web