1

I am a Linux beginner, and am having a problem with a drive which disappears from lsblk periodically, and am stuck with how to proceed. The drive is an 240GB external USB SSD.

Mounting the Drive Works

After plugging it in, I can see it appear with fdisk -l correctly:

enter image description here

Then I can mount it correctly and see it with lsblk:

enter image description here

and it also appears with df:

enter image description here

When the drive fails

Every few days the drive seems to just disappear completely from lsblk , df , and fdisk -l. At this point, I unplug and reconnect/remount the drive and it works again (but then disappears again after a couple of days). When the drive is working, I have tried to run both badblocks and smartctl, and both don't seem to indicate any problems with the drive:

enter image description here

enter image description here

Can anyone suggest a way to find out what is going on?


Edit

The machine is an INTEL NUC i5-3427U 8GB RAM 64GB M-SATA SSD, with a Kingston sa400s37240g hard drive:

enter image description here


Edit 2

Here is some output from the journalctl around the time that the drive seems to have disconnected itself:

root@pve:~# journalctl --since "02:00"
-- Journal begins at Fri 2023-01-20 17:07:18 GMT, ends at Thu 2023-11-16 14:07:51 GMT. --
Nov 16 02:00:01 pve CRON[357262]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Nov 16 02:00:01 pve CRON[357263]: (root) CMD (/usr/bin/touch /mnt/SSD_240GB/.keepalivefile)
Nov 16 02:00:01 pve CRON[357262]: pam_unix(cron:session): session closed for user root
Nov 16 02:10:47 pve kernel: sd 7:0:0:0: [sdc] tag#5 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD
Nov 16 02:10:47 pve kernel: sd 7:0:0:0: [sdc] tag#5 CDB: Write(10) 2a 00 0c 81 02 27 00 00 08 00
Nov 16 02:11:00 pve kernel: sd 7:0:0:0: [sdc] tag#4 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD
Nov 16 02:11:00 pve kernel: sd 7:0:0:0: [sdc] tag#4 CDB: Synchronize Cache(10) 35 00 00 00 00 00 00 00 00 00
Nov 16 02:11:00 pve kernel: scsi host7: uas_eh_device_reset_handler start
Nov 16 02:11:00 pve kernel: usb 2-1.6: reset high-speed USB device number 8 using ehci-pci
Nov 16 02:11:00 pve kernel: usb 2-1.6: device firmware changed
Nov 16 02:11:00 pve kernel: scsi host7: uas_eh_device_reset_handler FAILED err -19
Nov 16 02:11:00 pve kernel: sd 7:0:0:0: Device offlined - not ready after error recovery
Nov 16 02:11:00 pve kernel: sd 7:0:0:0: Device offlined - not ready after error recovery
Nov 16 02:11:00 pve kernel: sd 7:0:0:0: [sdc] tag#4 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK cmd_age=60s
Nov 16 02:11:00 pve kernel: sd 7:0:0:0: [sdc] tag#4 CDB: Synchronize Cache(10) 35 00 00 00 00 00 00 00 00 00
Nov 16 02:11:00 pve kernel: blk_update_request: I/O error, dev sdc, sector 231415655 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0
Nov 16 02:11:00 pve kernel: sd 7:0:0:0: [sdc] tag#5 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK cmd_age=44s
Nov 16 02:11:00 pve kernel: sd 7:0:0:0: [sdc] tag#5 CDB: Write(10) 2a 00 0c 81 02 27 00 00 08 00
Nov 16 02:11:00 pve kernel: blk_update_request: I/O error, dev sdc, sector 209781287 op 0x1:(WRITE) flags 0x103000 phys_seg 1 prio class 0
Nov 16 02:11:00 pve kernel: Buffer I/O error on dev sdc1, logical block 26214469, lost async page write
Nov 16 02:11:00 pve kernel: Aborting journal on device sdc1-8.

As well as some of the output from the syslog file:

root@pve:~# cat /var/log/syslog | grep -iEe 'Nov 16 02:1'
Nov 16 02:11:00 pve kernel: [1065272.885143] scsi host7: uas_eh_device_reset_handler start
Nov 16 02:11:00 pve kernel: [1065272.969137] usb 2-1.6: reset high-speed USB device number 8 using ehci-pci
Nov 16 02:11:00 pve systemd[1]: Unmounting /mnt/SSD_240GB...
Nov 16 02:11:00 pve systemd[1]: mnt-SSD_240GB.mount: Succeeded.
Nov 16 02:11:00 pve systemd[1]: Unmounted /mnt/SSD_240GB.
Nov 16 02:11:00 pve pvestatd[942]: status update time (12.435 seconds)
Nov 16 02:11:00 pve kernel: [1065273.425229] sd 7:0:0:0: [sdc] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
Nov 16 02:11:00 pve kernel: [1065273.505120] usb 2-1.6: new high-speed USB device number 9 using ehci-pci
Nov 16 02:11:00 pve kernel: [1065273.664305] usb 2-1.6: New USB device found, idVendor=174c, idProduct=55aa, bcdDevice= 1.00
Nov 16 02:11:00 pve kernel: [1065273.664314] usb 2-1.6: New USB device strings: Mfr=2, Product=3, SerialNumber=1
Nov 16 02:11:00 pve kernel: [1065273.664318] usb 2-1.6: Product: Best USB Device
Nov 16 02:11:00 pve kernel: [1065273.664320] usb 2-1.6: Manufacturer: ULT-Best
Nov 16 02:11:00 pve kernel: [1065273.664322] usb 2-1.6: SerialNumber: 042011210DC5
Nov 16 02:11:00 pve kernel: [1065273.664857] usb-storage 2-1.6:1.0: USB Mass Storage device detected
Nov 16 02:11:00 pve kernel: [1065273.665318] usb-storage 2-1.6:1.0: Quirks match for vid 174c pid 55aa: 400000
Nov 16 02:11:00 pve kernel: [1065273.665371] scsi host6: usb-storage 2-1.6:1.0
Nov 16 02:11:05 pve kernel: [1065278.371285] EXT4-fs error: 13 callbacks suppressed
Nov 16 02:11:05 pve kernel: [1065278.371295] EXT4-fs error (device sdc1): __ext4_find_entry:1663: inode #6553668: comm influxd: reading directory lblock 0

The OS and kernel versions are the following:

Operating System: Debian GNU/Linux 11 (bullseye)

Kernel: Linux 5.15.83-1-pve

10
  • 1
    I had a drive a few years ago that misbehaved in similar fashion. It turned out to be that the drive was designed to put itself to sleep. The solution (in my case) was to d/l software from the disk mfr website that could disable this "power saving" feature.
    – Seamus
    Commented Nov 14, 2023 at 13:22
  • Sorry, but I don't recall exactly how this all came to pass, but I do recall that my drive was a WesternDigital drive, and I got the software app from their website. Maybe Kingston has something similar?
    – Seamus
    Commented Nov 14, 2023 at 18:25
  • Look at the system's logs for disk events with the terminal command sudo journalctl -b 0 /dev/sdb.
    – waltinator
    Commented Nov 14, 2023 at 20:56
  • @teeeeee : when the drive disappears, the kernel removes probably the /dev/sdb special file : have the drive reappear first, and only afterwards run the journalctl command to see previous messages about it Commented Nov 16, 2023 at 14:03
  • The model you given is a SATA drive, so I assume you are using it with a USB enclosure/adapter? Does it get power with/from only one plug? (No barrel jack or Y-cable whatsoever?) And what's the host machine? Is it a raspberry pi or alike?
    – Tom Yan
    Commented Nov 16, 2023 at 14:07

2 Answers 2

1

Your problem is not with the disk, it is with the disk cable adapter.

The 174C code identifies it as ASMedia, which has some history of problems with the kernel driver.

Some people have had good results disabling UAS for those devices. Others, unfortunately, have had to change adapters altogether.

The problem is likely one of interrupt management/timing, since it occurs with much greater frequency on Raspberry PIs.

You can try what happens after giving the command below as root...

echo "174c:55aa:u" | tee /sys/module/usb_storage/parameters/quirks

...but your dmesg output makes me think that your device has already been quirked:

Nov 16 02:11:00 pve kernel: [1065273.665318] usb-storage 2-1.6:1.0: Quirks match for vid 174c pid 55aa: 400000

Someone else remarked that ASMedia sometimes changes the hardware under the hood, it might be possible that yours needs to be unquirked.

unquirking

The problem lies in detecting where the quirk has been stored. This might be in a modprobe file or in the boot loader.

We do know what the quirk looks for, so, as root,

grep -ri 174c:55aa /etc /boot

ought to find the vid/pid pair anywhere relevant. If it is in a modprobe.d file (probably /etc/modprobe.d/usbstoragequirks.conf or /etc/modprobe.d/usbstorage.conf), open the file, comment the quirk, and reboot (unloading/reloading the module should suffice, but still). If it is the grub config, something like

GRUB_CMDLINE_LINUX="usb_storage.quirks=174c:55aa:u"

just edit it out (add a comment with the old line for safety), then rebuild grub and reboot. After that, if the unit is a different hardware version where the quirk would not work, but the ordinary kernel code would, you should be all set. Wait a few days to be sure it works, and for added measure, disable the cache on the drive and, first thing, try reading, writing and MD5'ing both large files, and a unholy lot of very small files. That ought to shake off most of the bugs that might be lurking in there.

2
0

Edit: New answer

The syslog you posted might give us a clue: systemd

Please see this answer and check if your problem looks similar. Primarily, is your USB disk mount handled by systemd or is it a manual mount?

Furthermore, here's another answer for similar problem.

You might also want to detail your Linux distro and version.


Old answer, did not work

Sounds like the external drive goes into a power saving mode.

This article shows how to control USB device power settings.

Another option is to have a small "keepalive" script running with cron:

0 1  * * *  root  /usr/bin/touch /mnt/SSD-240GB/.keepalivefile

Put that to system crontab and restart cron. You can adjust the interval (now once a day at 1am) and the command if the disk still insist on going to sleep.

7
  • Thanks for the answer. I did as you suggested, but again after a couple of days the drive disappeared from lsblk and df. I think power saving might not be the problem. Can you suggest anything else?
    – teeeeee
    Commented Nov 16, 2023 at 12:10
  • @teeeeee Edited my answer (which looks more like a comment, but I can't add comments to the question yet).
    – karttu
    Commented Nov 16, 2023 at 15:00
  • Thanks a lot. The mount is handled by adding it to the fstab file, so that it mounts automatically on boot up (is this systemd then?). In the logs you talked about, yes it's true that systemd tries to unmount the device, but even before that it seems like some reset was already triggered, which we can see by the line uas_eh_device_reset_handler start.
    – teeeeee
    Commented Nov 16, 2023 at 15:06
  • Edited again with one additional answer I found. Is the drive disappearance frequency stable, i.e. does it always happen at the same time or after exactly same uptime? Is the external drive very hot to touch? I see it's bound to the NUC's heatsink - could you try to move the external drive away from the NUC for a few days?
    – karttu
    Commented Nov 16, 2023 at 15:11
  • It is not frequency stable, but it's a similar order. The last few times it happened, it was up for between 1 and 3 days each time.
    – teeeeee
    Commented Nov 16, 2023 at 15:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .