External Hard Drive stucked

Hello all,

I am using a Jetson TX2 and I plugged an external hard drive (exFAT, sudo mount /dev/sda2 /media/) for additional space. It works perfectly fine on a regular basis.

However, when I am writing large files (or many small files), it gets stuck at one point and it’s impossible to access the mount point (or to anything related to the hard drive). Also, some simple functions not linked to the external hard drive are very slow (even for a df -H). The only solution I found is to reboot the Jetson.

Do you have any idea how to fix this?

Thank you very much in advance.

PS: This is the information from fdisk -l :

Disk /dev/sda: 931,5 GiB, 1000170586112 bytes, 1953458176 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: FFD76242-B8B7-453B-B79F-E174ECD6DA53

Device      Start        End    Sectors   Size Type
/dev/sda1      40     409639     409600   200M EFI System
/dev/sda2  409640 1953456127 1953046488 931,3G Microsoft basic data

Same issue here, we need to restart the Jetson TX2, then remount th hard drive everytime after a handling a large file (>1GB).

1 Like

Can you keep a terminal running with “dmesg --follow”? Then note any errors which might show up. You could run this over ssh or serial console to guarantee that if the system crashes, then you still have the dmesg logs.

Thank you for your tip. I had a screen with dmesg --follow and then on another screen, I create a tar archive on the external hard drive with many folders. As expected, the external hard drive is stuck after some time but all the logs I have in dmesg are about UFW (so not link with our issue)

[UFW BLOCK] IN=eth0 OUT= MAC=33:33:00:00:00:fb:fc:45:96:a9:a9:db:86:dd SRC=fe80:0000:0000:0000:5071:e74e:d835:a896 DST=ff02:0000:0000:0000:0000:0000:0000:00fb LEN=76 TC=0 HOPLIMIT=1 FLOWLBL=899628 PROTO=UDP SPT=5353 DPT=5353 LEN=36


Some USB 3.0 UAS drive enclosures have issues in Linux. You might try an enclosure with a different chipset, or blocklisting the uas module for your particular enclosure.

The issue with that solution is that it will slow down drive access and increase CPU usage. Unfortunately the only good solution is to buy an enclosure that is specifically advertised for and tested with with Linux.

That may or may not be your issue, but if you find similar messages in dmesg, or the above fix resolves the issue, the enclosure’s chipset is probably the issue. It’s been my experience this is pretty rare, but it does happen.

I think you are correct that the log does not have anything to do with it, but if you are visible to an unprotected network, then there is some tiny (emphasis on “tiny”) possibility there is a denial of service of sorts going on. However, if that were the case, then I’d think it wouldn’t involve the drive. I am still curious though, do you have anything using UDP port 5353? I would guess what @mdegans mentions is the likely cause, but I don’t know how you’d test that (perhaps see if the same issues with the network cable removed).

If it turned out the issue is with the filesystem and not the drive, then are you free to reformat “/dev/sda2” as a native Linux type, e.g., ext4? Linux is most effiicent with its own filesystems, and if the problem continues, then you’ve essentially verified it isn’t the filesystem driver at issue (and it becomes more likely it is what @mdegans pointed out).

EDIT: Just thought of one more thing. Prior to the issue, save a copy of “/proc/interrupts”. After the issue hits, save another copy of “/proc/interrupts”. Post this to the forum. This might have some useful information.

1 Like