ubuntu-rockchip icon indicating copy to clipboard operation
ubuntu-rockchip copied to clipboard

Bug Report: External HDD connected via a USB's filesystem gets corrupt after a few hours/days

Open pricci1 opened this issue 1 year ago • 5 comments

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

pricci1 avatar Aug 17 '24 17:08 pricci1

I suspect the hard drive is not getting enough power, or your HDD is going bad.

Joshua-Riek avatar Aug 24 '24 14:08 Joshua-Riek

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.

pricci1 avatar Aug 24 '24 15:08 pricci1

HDD require between 5 to 9 watts of power, a USB 3.0 port can only provide 4.5 watts.

Joshua-Riek avatar Aug 24 '24 15:08 Joshua-Riek

They are 2.5" 5400rpm drives. Only one connected at a time

pricci1 avatar Aug 24 '24 16:08 pricci1

That doesn't change that they probably aren't getting enough power.

Use a powered USB hub and see if it persists.

SimplyCorbett avatar Sep 07 '24 02:09 SimplyCorbett

Will try with a USB hub. Thanks

pricci1 avatar Oct 12 '24 16:10 pricci1