Bug Report: External HDD connected via a USB's filesystem gets corrupt after a few hours/days
What happened?
Whenever I connect an external HDD via a USB 3.0 adapter, its filesystem gets corrupt after a few hours/days, making it read-only. I have to use e2fsck fix it (connecting it to another computer).
This has been happening to me with different drives and different USB adapters, across multiple installations of this OS.
Initially, many months ago while running 22.04 LTS server, I thought my HDD was failing, but SMART reported no errors, so I fixed the drive's fs and reinstalled the OS from scratch. No dice. Then I bought a brand new 1TB 2.5" HDD and the same happened. Back then I gave up on using external drives. Now I tried again, installed 24.04 server and connected another HDD I had around. After 3 days it failed again.
Any ideas what's going on, or how can I debug better?
Kernel version
6.1.0-1021-rockchip
SBC model
Orange Pi 5 Plus
What operating system are you seeing this problem on?
Ubuntu 24.04 LTS (Noble Nombat)
Relevant logs
This is the dmesg output when connecting the corrupted HDD (via USB) to another system:
[ 508.093734] sd 0:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB)
[ 508.093749] sd 0:0:0:0: [sda] 4096-byte physical blocks
[ 508.093964] sd 0:0:0:0: [sda] Write Protect is off
[ 508.093971] sd 0:0:0:0: [sda] Mode Sense: 53 00 00 08
[ 508.094315] sd 0:0:0:0: [sda] Disabling FUA
[ 508.094321] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 508.094525] sd 0:0:0:0: [sda] Preferred minimum I/O size 4096 bytes
[ 508.094531] sd 0:0:0:0: [sda] Optimal transfer size 33553920 bytes not a multiple of preferred minimum block size (4096 bytes)
[ 508.146302] sda: sda1
[ 508.146662] sd 0:0:0:0: [sda] Attached SCSI disk
[ 513.357113] EXT4-fs (sda1): warning: mounting fs with errors, running e2fsck is recommended
[ 513.380076] EXT4-fs (sda1): recovery complete
[ 513.399964] EXT4-fs (sda1): mounted filesystem 603704a1-256f-4cc2-a36f-47d0531d8a2f r/w with ordered data mode. Quota mode: disabled.
[ 522.233876] EXT4-fs error (device sda1): ext4_validate_block_bitmap:423: comm ext4lazyinit: bg 5454: bad block bitmap checksum
[ 522.233893] Aborting journal on device sda1-8.
[ 522.261648] EXT4-fs (sda1): Remounting filesystem read-only
[ 526.766255] EXT4-fs (sda1): unmounting filesystem 603704a1-256f-4cc2-a36f-47d0531d8a2f.
[ 527.777336] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 527.944204] sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
And this is the command I ran each time to recover the fs:
> sudo e2fsck /dev/sda1
e2fsck 1.47.1 (20-May-2024)
/dev/sda1: recovering journal
/dev/sda1 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Inode 29104818 extent tree (at level 2) could be narrower. Optimize<y>? yes
Inode 29104830 extent tree (at level 2) could be narrower. Optimize<y>? yes
Inode 29113826 extent tree (at level 1) could be shorter. Optimize<y>? yes
Pass 1E: Optimizing extent trees
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Unattached inode 29109940
Connect to /lost+found<y>? yes
Inode 29109940 ref count is 2, should be 1. Fix<y>? yes
Unattached inode 29109942
Connect to /lost+found<y>? yes
Inode 29109942 ref count is 2, should be 1. Fix<y>? yes
Unattached inode 29109943
Connect to /lost+found<y>? yes
Inode 29109943 ref count is 2, should be 1. Fix<y>? yes
Unattached inode 29109944
Connect to /lost+found<y>? yes
Inode 29109944 ref count is 2, should be 1. Fix<y>? yes
Pass 5: Checking group summary information
Block bitmap differences: +(119111680--119177215) -(178741248--178748275) -(178748992--178749439) -(183492863--183492887) -(183492991--183493183) -(183493375--183493439) -(183494719--183494783) -(183495295--183495359) -(183495615--183495679) -(183495935--183496063) -(183496447--183496511) -183496703 -(183497087--183497151) -(183497407--183497535) -(183497791--183497855) -(183497919--183497983) -(183498303--183498367) -(183498879--183498943) -(183499391--183499455) -(183499583--183499647) -(183499839--183499903) -(183499967--183500095) -183500799 -(183533631--183533695) -(183534079--183534143) -(183534271--183534399) -(183534463--183534527) -(183534783--183535039) -(183535103--183535167) -(183535616--183535679) -(183536511--183536575) -(183536703--183536831) -(183537215--183537279) -(183537535--183537599) -(183537664--183537727) -(183537983--183538047) -(183538559--183538623) -(183538751--183538815) -(183538943--183539007) -(183539647--183539711) -(183540223--183540287) -(183540671--183540735) -(183541183--183541503) -(183541695--183541759) -(183542591--183542719) -(183542783--183542847) -(183543103--183543167) -(183543295--183543359) -(183544383--183544447) -(183544895--183545023) -183545855 -(183546303--183546367) -(183546559--183546623) -(183547263--183547327) -(183548223--183548287) -(183548607--183548863) -(183548991--183549055) -(183549119--183549247) -(183549375--183549503) -(183549823--183549887) -(183551487--183551551) -(183552000--183552063) -(183552575--183552639) -(183553087--183553151) -(183553535--183553599) -(183554367--183554431) -(183554815--183554879) -(183555007--183555071) -(183555519--183555583) -(183555839--183555903) -(183556159--183556223) -(183556287--183556351) -(183556415--183556479) -(183557631--183557759) -(183558144--183558335) -(183558975--183559039) -(183559615--183559679) -(183559871--183559935) -(183559999--183560063) -(183560127--183560191) -(183560255--183560703) -(183560767--183560831) -(183561343--183561407) -(183561535--183561599) -183562239 -(183562623--183562687) -(183563135--183563199) -(183563391--183563583) -(183565439--183565503) -(183565631--183565695) -(183565823--183566015) +(213286912--213331988) +(213334016--213352447) +(213417984--213549055)
Fix<y>? yes
Free blocks count wrong for group #5454 (1113, counted=9305).
Fix<y>? yes
Free blocks count wrong (35884765, counted=35892957).
Fix<y>? yes
/dev/sda1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sda1: 69088/61054976 files (2.0% non-contiguous), 208297251/244190208 blocks
edit: Forgot to mention:
- This doesn't happen to the NVMe drive (connected in the M.2 slot)
- Tested connecting one of the drives using one of the USB adapters to another machine for a week and no fs corruption occurred
I suspect the hard drive is not getting enough power, or your HDD is going bad.
I tried with a brand new HDD, and the same happened. It might be the power supply, but it's the official one. The only things I have attached to the SBC are the eMMC chip, a small fan and the USB connected drive.
HDD require between 5 to 9 watts of power, a USB 3.0 port can only provide 4.5 watts.
They are 2.5" 5400rpm drives. Only one connected at a time
That doesn't change that they probably aren't getting enough power.
Use a powered USB hub and see if it persists.
Will try with a USB hub. Thanks