Re: Damaged filesystem - request for support

[Nicholas D Steeves <nsteeves@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5148 bytes --]

Hi Tobiasz,

Tobiasz Karoń <unfa00@gmail.com> writes:

> [Wed Nov 12 11:11:01 2025] sd 2:0:0:0: [sdc] tag#5
> uas_eh_abort_handler 0 uas-tag 1 inflight: CMD
> [Wed Nov 12 11:11:01 2025] sd 2:0:0:0: [sdc] tag#5 CDB: ATA command
> pass through(16) 85 06 0c 00 d4 00 00 00 82 00 4f 00 c2 00 b0 00
> [Wed Nov 12 11:11:01 2025] scsi host2: uas_eh_device_reset_handler start
> [Wed Nov 12 11:11:01 2025] usb 4-1.2: reset SuperSpeed USB device
> number 7 using xhci_hcd
> [Wed Nov 12 11:11:01 2025] scsi host2: uas_eh_device_reset_handler success
>
> That happens after a minute wheenver I do:
> smartctl -l long -C /dev/sdc
>
> So it seems I can't do a long, captive HDD test through this enclosure.
> This is the self-test log for the drive:

USB attached disks, even directly attached (like WD Passport*) without a
SATA2USB bridge are unfortunately often...special...this way.  The way
to run a long SMART test on them (if the controller isn't uselessly
buggy) is to use a "while true" loop to do something like dd a block
from /dev/urandom to /mnt/point/delete_me, sleep for a period shorter
than then the enclosure's sleep timeout (IIRC there are bad controllers
that will always sleep even if you tell them not to), sync, allow to
iterate, and interrupt the loop after you've allowed the long test to
complete, plus an hour, plus checked the self-test log (checking the log
will abort a running test!).  I've also, 3× now, run into disks that
marked blocks for reallocation, in firmware, during their first write ->
read_verify-write cycle, wrote to the manufacturer (three different
manufacturers), and was told that was normal--oh brave new world.

> root@pve:/mnt# smartctl -l xselftest /dev/sdc
> smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.8.12-16-pve] (local build)
> Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org
>
> === START OF READ SMART DATA SECTION ===
> SMART Extended Self-test Log Version: 1 (1 sectors)
> Num  Test_Description    Status                  Remaining
> LifeTime(hours)  LBA_of_first_error
> # 1  Extended captive    Interrupted (host reset)      90%        42         -
> # 2  Extended captive    Interrupted (host reset)      90%        42         -
> # 3  Extended offline    Aborted by host               90%        42         -
> # 4  Extended offline    Aborted by host               90%         1         -
>
> I have tested blacklisting the uas driver, but the enclosure would
> just not show up (should I load an alternative driver for it?)
> lsusb says this about the 2-bay disk enclosure:
> Bus 004 Device 007: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA
> 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge,
> ASM1153E SATA 6Gb/s bridge
>
> I wonder if there's something that can be done about this enclosure in
> terms of patching the driver or something?
> Should I contact a different mailing list?
> This is by no means Btrfs-specific at this point.

I don't have experience with this chipset, and someone[s] in the
following thread maintain[s] that it works fine in UASP mode in 2022 (it
is documented in various places that it was not fine in 2015).
https://forums.raspberrypi.com/viewtopic.php?t=339591&start=25

> About write cache disabling, I was unable to do it persistently with
> hdparm, but I found that there's a way to disable write caching
> persistently with smartclt. It's also possible to disable write cache
> reordering, which I suppose could be more dangerous fro Btrfs. I have
> once used bcache with Btrfs in writeback mode and after a particular
> system crash the FS has gone bad. (I've even written a song about
> it..)
> smartctl -s wcreorder=off,p /dev/sdc
>
> I have attempted to disable autosuspend for all xhci controlers using PowerTop:

Have you tried adding "usbcore.autosuspend=-1" to your kernel arguments?
(ie: /etc/default/grub, then run `update-grub`).

>   Good          Enable SATA link power management for host0
>   Good          Enable Audio codec power management
>   Bad           Autosuspend for USB device xHCI Host Controller [usb1]
>   Good          Autosuspend for USB device USB2.0 Hub
> [VIA Labs, Inc.         ]
>   Good          Autosuspend for USB device USB2.0 Hub [1-1]
>   Good          Autosuspend for USB device USB2.1 Hub [Generic]
>   Bad           Autosuspend for USB device xHCI Host Controller [usb3]
>   Good          Autosuspend for USB device USB3.0 Hub
> [VIA Labs, Inc.         ]
>   Bad           Autosuspend for USB device xHCI Host Controller [usb2]
>   Good          Autosuspend for USB device USB3.2 Hub [Generic]
>   Bad           Autosuspend for USB device xHCI Host Controller [usb4]

How is VIA's xHCI support for UASP?  Missing usb-host quirks could
hypothetically be needed, and USB device manufacturers sometimes assume
Intel to such an extent that there have been cases where the hardware
(I'm thinking of a handful of audio interfaces) didn't work at all on
AMD motherboards of that era.  I assume this class of issue can be
mitigated in-kernel.

Cheers,
Nicholas

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]