Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #273231
| 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 |
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
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