Created attachment 1713166 [details] Kernel logs 1. Please describe the problem: Kernel issues writesame_16 instead of unmap on a WD BLACK P10 external hard drive. The WD BLACK P10 5TB external hard drive probably uses a SMR technology. It reports TRIM support (can be verified by lsblk -D). However, issuing TRIM operations (e.g., blkdiscard /dev/sdX) results in error messages in dmesg: [ 847.717368] sd 6:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [ 847.717371] sd 6:0:0:0: [sdb] tag#0 Sense Key : Illegal Request [current] [ 847.717373] sd 6:0:0:0: [sdb] tag#0 Add. Sense: Invalid command operation code [ 847.717375] sd 6:0:0:0: [sdb] tag#0 CDB: Write same(16) 93 08 00 00 00 00 00 00 00 00 00 7f ff f8 00 00 [ 847.717378] blk_update_request: critical target error, dev sdb, sector 0 op 0x3:(DISCARD) flags 0x4000 phys_seg 1 prio class 0 [ 847.717403] blk_update_request: I/O error, dev sdb, sector 8388600 op 0x3:(DISCARD) flags 0x0 phys_seg 1 prio class 0 [ 847.717425] blk_update_request: I/O error, dev sdb, sector 8388607 op 0x3:(DISCARD) flags 0x4000 phys_seg 1 prio class 0 [ 847.717690] blk_update_request: I/O error, dev sdb, sector 16777200 op 0x3:(DISCARD) flags 0x0 phys_seg 1 prio class 0 This is because the kernel incorrectly determines that writesame_16 operation should be used: $ cat /sys/block/sdb/device/scsi_disk/6\:0\:0\:0/provisioning_mode writesame_16 But the correct operation is unmap: $ sudo sg_vpd -a /dev/sdb Logical block provisioning VPD page (SBC): Unmap command supported (LBPU): 1 Write same (16) with unmap bit supported (LBPWS): 0 Write same (10) with unmap bit supported (LBPWS10): 0 Logical block provisioning read zeros (LBPRZ): 0 After changing the value of provisioning_mode to 'unmap', TRIM works. This can be verified by reading trimmed area on the hard drive, it returns zeros. However, this change is not persistent and is automatically replaced by 'writesame_16'. 2. What is the Version-Release number of the kernel: $ uname -a Linux david-pc.localdomain 5.8.4-200.fc32.x86_64 #1 SMP Wed Aug 26 22:28:08 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 : It affects both kernels that I've tried, the 5.8.4 kernel and the 5.7.17 kernel. 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: Connect a WD BLACK P10 hard drive to a USB 3.0 port, run sudo blkdiscard -v /dev/sdX 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: 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.
*** Bug 1874083 has been marked as a duplicate of this bug. ***
On Fedora 33 (kernel 5.10.13-200.fc33.x86_64 #1 SMP Thu Feb 4 14:54:51 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux) with similar WD external 5TiB USB drive, dmesg has: scsi 5:0:0:0: Direct-Access WD My Book 25EE 4009 PQ: 0 ANSI: 6 scsi 5:0:0:1: Enclosure WD SES Device 4009 PQ: 0 ANSI: 6 sd 5:0:0:0: Attached scsi generic sg2 type 0 scsi 5:0:0:1: Attached scsi generic sg3 type 13 sd 5:0:0:0: [sdb] Very big device. Trying to use READ CAPACITY(16). sd 5:0:0:0: [sdb] 11721043968 512-byte logical blocks: (6.00 TB/5.46 TiB) sd 5:0:0:0: [sdb] 4096-byte physical blocks sd 5:0:0:0: [sdb] Write Protect is off sd 5:0:0:0: [sdb] Mode Sense: 47 00 10 08 sd 5:0:0:0: [sdb] No Caching mode page found sd 5:0:0:0: [sdb] Assuming drive cache: write through sdb: sdb1 sdb2 sdb3 sd 5:0:0:0: [sdb] Attached SCSI disk [... several days pass] sd 5:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s sd 5:0:0:0: [sdb] tag#0 Sense Key : Illegal Request [current] sd 5:0:0:0: [sdb] tag#0 Add. Sense: Invalid command operation code sd 5:0:0:0: [sdb] tag#0 CDB: Write same(16) 93 08 00 00 00 01 17 7e f6 38 00 7f ff f8 00 00 blk_update_request: critical target error, dev sdb, sector 4689163832 op 0x3:(DISCARD) flags 0x4000 phys_seg 1 prio class 0 blk_update_request: I/O error, dev sdb, sector 4697552432 op 0x3:(DISCARD) flags 0x0 phys_seg 1 prio class 0 and: sudo sg_vpd --page=0xb2 /dev/sdb Logical block provisioning VPD page (SBC): Unmap command supported (LBPU): 1 Write same (16) with unmap bit supported (LBPWS): 0 Write same (10) with unmap bit supported (LBPWS10): 0 Logical block provisioning read zeros (LBPRZ): 0 Anchored LBAs supported (ANC_SUP): 0 Threshold exponent: 0 [threshold sets not supported] Descriptor present (DP): 0 Minimum percentage: 0 [not reported] Provisioning type: 1 (resource provisioned) Threshold percentage: 0 [percentages not supported] but (unlike the original report): cat /sys/block/sdb/device/scsi_disk/5:0:0:0/provisioning_mode disabled https://patchwork.kernel.org/project/dm-devel/patch/20130919161043.GA27081@redhat.com/ discusses WRITE SAME heuristics. I gather that heuristics can mistakenly activate WRITE SAME but will disable it on the error, so this might be expected behaviour. I'll check `provisioning_mode` after a reboot.
After a reboot: cat /sys/block/sdb/device/scsi_disk/5:0:0:0/provisioning_mode writesame_16
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.