Bug 1889146
| Summary: | fstrim fails to trim file systems on LVM raid volumes | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Thomas Köller <thomas> |
| Component: | dmraid | Assignee: | LVM and device-mapper development team <lvm-team> |
| Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 32 | CC: | agk, bmr, cfeist, heinzm, jonathan, kzak, lvm-team, mcsontos, prajnoha, prockai, zkabelac |
| Target Milestone: | --- | Flags: | thomas:
needinfo-
|
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-10-27 18:35:56 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Thomas Köller
2020-10-18 12:32:05 UTC
Please, try cat /sys/block/<name>/queue/discard_granularity with proper kernel device name for /dev/mapper/SysStorage-HomeFS (for example "lsblk -o KNAME /dev/mapper/SysStorage-HomeFS") retruns the name, or you can try "lsblk --discard" to get complete overview. Note that fstrim ignores devices with zero discard_granularity (or DISC-GRAN in lsblk output). (In reply to Karel Zak from comment #1) > Please, try > > cat /sys/block/<name>/queue/discard_granularity > > with proper kernel device name for /dev/mapper/SysStorage-HomeFS (for > example "lsblk -o KNAME /dev/mapper/SysStorage-HomeFS") retruns the name, > [thomas@sarkovy ~]$ lsblk -o KNAME /dev/mapper/SysStorage-HomeFS KNAME dm-9 [thomas@sarkovy ~]$ cat /sys/block/dm-9/queue/discard_granularity 0 [thomas@sarkovy ~]$ lsblk -o KNAME /dev/mapper/SysStorage-RootFS KNAME dm-4 [thomas@sarkovy ~]$ cat /sys/block/dm-4/queue/discard_granularity 0 > or you can try "lsblk --discard" to get complete overview. > [thomas@sarkovy ~]$ lsblk --discard NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO sda 0 512B 2G 0 ├─sda1 0 512B 2G 0 └─sda2 0 512B 2G 0 ├─SysStorage-RootFS_rmeta_0 0 512B 2G 0 │ └─SysStorage-RootFS 0 0B 0B 0 ├─SysStorage-RootFS_rimage_0 0 512B 2G 0 │ └─SysStorage-RootFS 0 0B 0B 0 ├─SysStorage-HomeFS_rmeta_0 0 512B 2G 0 │ └─SysStorage-HomeFS 0 0B 0B 0 └─SysStorage-HomeFS_rimage_0 0 512B 2G 0 └─SysStorage-HomeFS 0 0B 0B 0 sdb 0 512B 2G 0 ├─sdb1 0 512B 2G 0 ├─sdb2 0 512B 2G 0 │ ├─SysStorage-RootFS_rmeta_1 0 512B 2G 0 │ │ └─SysStorage-RootFS 0 0B 0B 0 │ ├─SysStorage-RootFS_rimage_1 0 512B 2G 0 │ │ └─SysStorage-RootFS 0 0B 0B 0 │ ├─SysStorage-HomeFS_rmeta_1 0 512B 2G 0 │ │ └─SysStorage-HomeFS 0 0B 0B 0 │ └─SysStorage-HomeFS_rimage_1 0 512B 2G 0 │ └─SysStorage-HomeFS 0 0B 0B 0 └─sdb3 0 512B 2G 0 sdc 0 0B 0B 0 └─sdc2 0 0B 0B 0 sdd 0 0B 0B 0 sde 0 0B 0B 0 └─sde2 0 0B 0B 0 sr0 0 0B 0B 0 Thanks for details. It's obvious (from lsblk --discard) that LVM does not follow discard_granularity from original devices. Reassigning to LVM team. I'm wondering how is this related to this kernel commit: f0e90b6c663a7e3b4736cb318c6c7c589f152c28 https://github.com/torvalds/linux/commit/f0e90b6c663a7e3b4736cb318c6c7c589f152c28 Please retest with kernel 5.9 which should have this fix included. For completeness this patch was added to this earlier one - e0910c8e4f87bb9f767e61a778b0d9271c4dc512 https://github.com/torvalds/linux/commit/e0910c8e4f87bb9f767e61a778b0d9271c4dc512 (In reply to Zdenek Kabelac from comment #4) > I'm wondering how is this related to this kernel commit: > f0e90b6c663a7e3b4736cb318c6c7c589f152c28 > > https://github.com/torvalds/linux/commit/ > f0e90b6c663a7e3b4736cb318c6c7c589f152c28 > > Please retest with kernel 5.9 which should have this fix included. I have a raid1 configuration, so this is most likely unrelated. (In reply to Thomas Köller from comment #6) > (In reply to Zdenek Kabelac from comment #4) > > I'm wondering how is this related to this kernel commit: > > f0e90b6c663a7e3b4736cb318c6c7c589f152c28 > > > > https://github.com/torvalds/linux/commit/ > > f0e90b6c663a7e3b4736cb318c6c7c589f152c28 > > > > Please retest with kernel 5.9 which should have this fix included. > > I have a raid1 configuration, so this is most likely unrelated. See the 'starting' patch in comment 5, (in comment 4 there was the final patch of this). Please retest with 5.9 and let us know. > Please retest with 5.9 and let us know.
Seems there is currently no 5.9 kernel for fedora, not even in rawhide, or am I missing something?
(In reply to Thomas Köller from comment #8) > > Please retest with 5.9 and let us know. > > Seems there is currently no 5.9 kernel for fedora, not even in rawhide, or > am I missing something? I'm running myself no-debug repo kernel: 5.9.0-36.fc34.x86_64 See the outcome of this link: https://koji.fedoraproject.org/koji/packageinfo?packageID=8 Problem still exists in kernel 5.9.0:
[root@sarkovy ~]# uname -a
Linux sarkovy 5.9.0-36.fc34.x86_64 #1 SMP Mon Oct 12 13:40:33 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
[root@sarkovy ~]# fstrim -vna
/boot/efi: 0 B (dry run) trimmed on /dev/sda1
/boot: 0 B (dry run) trimmed on /dev/sdb3
[root@sarkovy ~]# lsblk --discard
NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda 0 512B 2G 0
├─sda1 0 512B 2G 0
└─sda2 0 512B 2G 0
├─SysStorage-RootFS_rmeta_0 0 512B 2G 0
│ └─SysStorage-RootFS 0 0B 0B 0
├─SysStorage-RootFS_rimage_0 0 512B 2G 0
│ └─SysStorage-RootFS 0 0B 0B 0
├─SysStorage-HomeFS_rmeta_0 0 512B 2G 0
│ └─SysStorage-HomeFS 0 0B 0B 0
└─SysStorage-HomeFS_rimage_0 0 512B 2G 0
└─SysStorage-HomeFS 0 0B 0B 0
sdb 0 512B 2G 0
├─sdb1 0 512B 2G 0
├─sdb2 0 512B 2G 0
│ ├─SysStorage-RootFS_rmeta_1 0 512B 2G 0
│ │ └─SysStorage-RootFS 0 0B 0B 0
│ ├─SysStorage-RootFS_rimage_1 0 512B 2G 0
│ │ └─SysStorage-RootFS 0 0B 0B 0
│ ├─SysStorage-HomeFS_rmeta_1 0 512B 2G 0
│ │ └─SysStorage-HomeFS 0 0B 0B 0
│ └─SysStorage-HomeFS_rimage_1 0 512B 2G 0
│ └─SysStorage-HomeFS 0 0B 0B 0
└─sdb3 0 512B 2G 0
sdc 0 0B 0B 0
└─sdc2 0 0B 0B 0
sdd 0 0B 0B 0
sde 0 0B 0B 0
└─sde2 0 0B 0B 0
sr0 0 0B 0B 0
So now - lvm2 --type raid0 is supported. And quite likely --type raid1 seems still unsupported. Passing to Heinz for more insight comments (as I've believe it's been modified in past already). Ok - seems the patch has not landed in 5.9 Please retry with now available: 5.10.0-0.rc1.56.fc34.x86_64 This should give you non-zero granularity. As Zdenek mentioned in the previous comment, with recent upstream kernels raid0/1/10 RaidLVs allow to process discards, thus fstrim will work. Nonetheless, raid4/5/6 RaidLVs would need the dm-raid module parameter devices_handle_discard_safely set to 'Y' but that presumes _knowing_ all PVs with such RaidLV allocations return zeroes reliably on reads from discarded blocks! Besides, the same module paramter setting is needed for native MD's raid456 module to allow for discards. |