DescriptionLukas Slebodnik
2020-10-19 15:51:26 UTC
1. Please describe the problem:
I check log from fstrim.service from time to time and I could not see trimming /home in last few days.
I tried manually and it returned fstrim: /home: the discard operation is not supported.
sh# fstrim -v /home
fstrim: /home: the discard operation is not supported
sh# strace -Z fstrim /home
arch_prctl(0x3001 /* ARCH_??? */, 0x7fffdfe2c5c0) = -1 EINVAL (Invalid argument)
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
ioctl(3, FITRIM, {start=0, len=0xffffffffffffffff, minlen=0}) = -1 EOPNOTSUPP (Operation not supported)
It still work on /boot which is ext4 as well and also with "root" / whihc is luks + btrfs
sh-5.0# fstrim -va
/boot: 24.4 MiB (25550848 bytes) trimmed on /dev/nvme0n1p1
/: 3.7 GiB (3988697088 bytes) trimmed on /dev/mapper/luks-0f8d83fa-5cf9-43e7-82da-8fb5a81a0621
sh-5.0# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme0n1 259:0 0 238.5G 0 disk
├─nvme0n1p1 259:1 0 3G 0 part /boot
├─nvme0n1p2 259:2 0 100G 0 part
│ └─luks-0f8d83fa-5cf9-43e7-82da-8fb5a81a0621 253:1 0 100G 0 crypt /
└─nvme0n1p3 259:3 0 135.5G 0 part
└─luks-38c8cdbc-292c-4bcd-9275-404d5ba2a119 253:0 0 135.5G 0 crypt
├─fedora-home 253:2 0 100G 0 lvm /home
└─fedora-swap 253:3 0 35.5G 0 lvm [SWAP]
sh-5.0# blkid
/dev/nvme0n1p1: UUID="9d4311d8-acfa-4657-af5f-d9ccabb4a7c2" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="00012ec8-01"
/dev/nvme0n1p2: UUID="0f8d83fa-5cf9-43e7-82da-8fb5a81a0621" TYPE="crypto_LUKS" PARTUUID="00012ec8-02"
/dev/nvme0n1p3: UUID="38c8cdbc-292c-4bcd-9275-404d5ba2a119" TYPE="crypto_LUKS" PARTUUID="00012ec8-03"
/dev/mapper/luks-38c8cdbc-292c-4bcd-9275-404d5ba2a119: UUID="N7IqF5-PITu-vlne-HD6e-YYjO-iVrI-FiKhJQ" TYPE="LVM2_member"
/dev/mapper/luks-0f8d83fa-5cf9-43e7-82da-8fb5a81a0621: UUID="391bb71d-f1d7-41c1-b2dd-446843be9ee8" UUID_SUB="b9f06d72-33a9-4122-8c0b-12d15ac3c2f0" BLOCK_SIZE="4096" TYPE="btrfs"
/dev/mapper/fedora-home: LABEL="home" UUID="87d8dfc3-7012-42ff-ac6c-24242c05ffc5" BLOCK_SIZE="4096" TYPE="ext4"
/dev/mapper/fedora-swap: LABEL="swap" UUID="28fde753-295c-4a9c-b9ee-7844de277d4b" TYPE="swap"
2. What is the Version-Release number of the kernel:
sh-5.0# uname -a
Linux localhost.localdomain 5.8.15-201.fc32.x86_64 #1 SMP Thu Oct 15 15:56:44 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
3. Did it work previously in Fedora? If so, what kernel version did the issue
*first* appear? Old kernels are available for download at
https://koji.fedoraproject.org/koji/packageinfo?packageID=8 :
I cannot reproduce with latest 5.7 from koji (kernel-core-5.7.17-200.fc32.x86_64)
4. Can you reproduce this issue? If so, please provide the steps to reproduce
the issue below:
I can reproduce on my laptop; did not try in VM.
6. Are you running any modules that not shipped with directly Fedora's kernel?:
No
7. Please attach the kernel logs. You can get the complete kernel log
for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
issue occurred on a previous boot, use the journalctl ``-b`` flag.
There is nothing in journal or dmesg for problematic "fstrim -v /home/"
I tried to bisect on 5.8.x from koji and 5.8.15-200.fc32.x86_64 worked for me.
I reinstalled 5.8.15-201.fc32.x86_64 and I am not bale to reproduce anymore.
1. Please describe the problem: I check log from fstrim.service from time to time and I could not see trimming /home in last few days. I tried manually and it returned fstrim: /home: the discard operation is not supported. sh# fstrim -v /home fstrim: /home: the discard operation is not supported sh# strace -Z fstrim /home arch_prctl(0x3001 /* ARCH_??? */, 0x7fffdfe2c5c0) = -1 EINVAL (Invalid argument) access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) ioctl(3, FITRIM, {start=0, len=0xffffffffffffffff, minlen=0}) = -1 EOPNOTSUPP (Operation not supported) It still work on /boot which is ext4 as well and also with "root" / whihc is luks + btrfs sh-5.0# fstrim -va /boot: 24.4 MiB (25550848 bytes) trimmed on /dev/nvme0n1p1 /: 3.7 GiB (3988697088 bytes) trimmed on /dev/mapper/luks-0f8d83fa-5cf9-43e7-82da-8fb5a81a0621 sh-5.0# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT nvme0n1 259:0 0 238.5G 0 disk ├─nvme0n1p1 259:1 0 3G 0 part /boot ├─nvme0n1p2 259:2 0 100G 0 part │ └─luks-0f8d83fa-5cf9-43e7-82da-8fb5a81a0621 253:1 0 100G 0 crypt / └─nvme0n1p3 259:3 0 135.5G 0 part └─luks-38c8cdbc-292c-4bcd-9275-404d5ba2a119 253:0 0 135.5G 0 crypt ├─fedora-home 253:2 0 100G 0 lvm /home └─fedora-swap 253:3 0 35.5G 0 lvm [SWAP] sh-5.0# blkid /dev/nvme0n1p1: UUID="9d4311d8-acfa-4657-af5f-d9ccabb4a7c2" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="00012ec8-01" /dev/nvme0n1p2: UUID="0f8d83fa-5cf9-43e7-82da-8fb5a81a0621" TYPE="crypto_LUKS" PARTUUID="00012ec8-02" /dev/nvme0n1p3: UUID="38c8cdbc-292c-4bcd-9275-404d5ba2a119" TYPE="crypto_LUKS" PARTUUID="00012ec8-03" /dev/mapper/luks-38c8cdbc-292c-4bcd-9275-404d5ba2a119: UUID="N7IqF5-PITu-vlne-HD6e-YYjO-iVrI-FiKhJQ" TYPE="LVM2_member" /dev/mapper/luks-0f8d83fa-5cf9-43e7-82da-8fb5a81a0621: UUID="391bb71d-f1d7-41c1-b2dd-446843be9ee8" UUID_SUB="b9f06d72-33a9-4122-8c0b-12d15ac3c2f0" BLOCK_SIZE="4096" TYPE="btrfs" /dev/mapper/fedora-home: LABEL="home" UUID="87d8dfc3-7012-42ff-ac6c-24242c05ffc5" BLOCK_SIZE="4096" TYPE="ext4" /dev/mapper/fedora-swap: LABEL="swap" UUID="28fde753-295c-4a9c-b9ee-7844de277d4b" TYPE="swap" 2. What is the Version-Release number of the kernel: sh-5.0# uname -a Linux localhost.localdomain 5.8.15-201.fc32.x86_64 #1 SMP Thu Oct 15 15:56:44 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : I cannot reproduce with latest 5.7 from koji (kernel-core-5.7.17-200.fc32.x86_64) 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: I can reproduce on my laptop; did not try in VM. 6. Are you running any modules that not shipped with directly Fedora's kernel?: No 7. Please attach the kernel logs. You can get the complete kernel log for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the issue occurred on a previous boot, use the journalctl ``-b`` flag. There is nothing in journal or dmesg for problematic "fstrim -v /home/"