On Mon, Feb 12, 2024 at 04:52:09PM +0100, Martin Steigerwald wrote:
Kent Overstreet - 11.02.24, 19:51:32 CET:
On Sun, Feb 11, 2024 at 06:06:27PM +0100, Martin Steigerwald wrote:
[…]
CC'ing BCacheFS mailing list.
My original mail is here:
https://lore.kernel.org/linux-usb/5264d425-fc13-6a77-2dbf-6853479051a0 @applied-asynchrony.com/T/ #m5ec9ecad1240edfbf41ad63c7aeeb6aa6ea38a5e
Holger Hoffstätte - 11.02.24, 17:02:29 CET:
On 2024-02-11 16:42, Martin Steigerwald wrote:
Hi! I am trying to put data on an external Kingston XS-2000 4 TB SSD using self-compiled Linux 6.7.4 kernel and encrypted BCacheFS. I do not think BCacheFS has any part in the errors I see, but if you disagree feel free to CC the BCacheFS mailing list as you reply.
This is indeed a known bug with bcachefs on USB-connected devices. Apply the following commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/c ommi t/fs/bcachefs?id=3e44f325f6f75078cdcd44cd337f517ba3650d05
This and some other commits are already scheduled for -stable.
Thanks!
Oh my. I was aware of some bug fixes coming for stable. I briefly looked through them, but now I did not make a connection.
I will wait for 6.7.5 and retry then I bet.
That doesn't look related - the device claims to not support flush or fua, and the bug resulted in us not sending flush/fua devices; the main thing people would see without that patch, on 6.8, would be an immediate -EOPNOTSUP on the first flush journal write.
He only got errors after an hour or so, or 10 minutes with UAS disabled; we send flushes once a second. Sounds like a screwy device.
Thanks for that explanation, Kent.
I am the one with that external Transcend XS 2000 4 TB SSD and I specifically did not CC bcachefs mailing list at the beginning as after seeing things like
[33963.462694] sd 0:0:0:0: [sda] tag#10 uas_zap_pending 0 uas-tag 1 inflight: CMD [33963.462708] sd 0:0:0:0: [sda] tag#10 CDB: Write(16) 8a 00 00 00 00 00 82 c1 bc 00 00 00 04 00 00 00 […] [33963.592872] sd 0:0:0:0: [sda] tag#10 FAILED Result: hostbyte=DID_RESET driverbyte=DRIVER_OK cmd_age=182s
I thought some quirks in the device to be at fault.
However while Sandisk Extreme Pro 2 TB claims to support DPO and FUA I see
Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
also with other devices like external Toshiba Canvio 4 TB hard disks. Using LUKS encrypted BTRFS on those I never saw any timeout while writing out data issue with any of those hard disks. Also with disabled write cache any cache flush / FUA request should be a no-op anyway? These hard disks have been doing a ton of backup workloads without any issues, but so far only with BTRFS.
I may test the Transcend XS2000 with BTRFS to see whether it makes a difference, however I really like to use it with BCacheFS and I do not really like to use LUKS for external devices. According to the kernel log I still don't really think those errors at the block layer were about anything filesystem specific, but what do I know?
It's definitely not unheard of for one specific filesystem to be tickling driver/device bugs and not others.
I wonder what it would take to dump the outstanding requests on device timeout.