On FreeBSD 13.0-RELEASE-p11 under VMWARE ESXI 7.0U2a fsck run on a UFS filesystem with journaled soft-updates enables cannot access journal file. When fsck fails to access .sujournal Kernel messages show: May 9 13:38:50 nas3 kernel: pvscsi0: pvscsi_execute_ccb error 27 May 9 13:38:50 nas3 syslogd: last message repeated 1 times May 9 13:38:50 nas3 kernel: (da1:pvscsi0:0:1:0): READ(10). CDB: 28 00 00 00 a9 c0 00 04 00 00 May 9 13:38:50 nas3 kernel: (da1:pvscsi0:0:1:0): CAM status: The request was too large for this host May 9 13:38:50 nas3 kernel: (da1:pvscsi0:0:1:0): Error 22, Unretryable error May 9 13:38:50 nas3 kernel: (da1:pvscsi0:0:1:0): READ(10). CDB: 28 00 00 00 ad c0 00 04 00 00 May 9 13:38:50 nas3 kernel: (da1:pvscsi0:0:1:0): CAM status: The request was too large for this host May 9 13:38:50 nas3 kernel: (da1:pvscsi0:0:1:0): Error 22, Unretryable error Placing kern.maxphys="131072" in /boot/loader.conf remedies problem with fsck a possible problem with pvscsi.ko kernel module?
This bug still exists in 13.1-RELEASE
This is very annoying bug. When installing TrueNAS-13.0-U1 on VMWARE ESXI 7.0U2 you will encounter it twice. 1. On installation (you want be able to select disks). You need to tweak the .iso. My recommendation is to use hex editor, find a text '# Boot loader file for TrueNAS.' and replace it with 'kern.maxphys="131072"' (fill the rest with spaces). 2. On adding disks to pool (you won't be able to format them). This time it's easier, just go to /boot/loader.conf and add 'kern.maxphys="131072"' and restart.
Unfortunately fix implemented more than a year ago was not merged to stable/13 branch. I've merged it recently after I hit the same issue.
(In reply to Alexander Motin from comment #3) Would you mind adding a URL to the commit to this issue?
https://cgit.freebsd.org/src/commit/sys/dev/vmware/pvscsi/pvscsi.c?h=stable/13&id=f51c1d1dd595ce51059489d7e1248ff6ba39664a
Created attachment 238278 [details] script to trigger the bug Hi, I still see this on CURRENT. It gets easily triggered by gunion: sh g_union.sh da1p1 da1p2 (Regarding NVMe: sh g_union.sh nvd0p1 nvd0p2 deadlocks as well printing "nvme0: nvme_payload_map err 27") The script is attached
Triage: * assignment to the committer of f51c1d1dd595ce51059489d7e1248ff6ba39664a (thanks for the then fix/resolution) * CC author * reopen, or make a new report for comment 6?