Setting Up RPi4 64Bit

That one is not designed to be used as a boot drive. It will wear out rather quicly. If you want to use WD/Sandisk stuff – try WD Purple SD cards – they have confirmed wear leveling working, albeit not described in the data sheet enter.

since you already have it, use iotop or other tools to track down and eliminate as much writes from it as possible.

Any clues on what? What is the question?

on how to solve it? is there anything i can do?

You need to provide way more details.

On what disk? Is this your boot disk? USB3 disk connected to the pi? Did you disable UAS? Did you use powered hub to connect to pi? Does your USB disk adapter support SMART? Did you read SMART attributes from the disk? Have you ran long SMART test? Did it actually report bad/reallocated sectors after the test completed? What file failed to read?

well it’s on dev/sdb1, monted at a HDS/HD2! The answer is yes… it has smart capabilities!

storagewars@raspberrypi:~ $ sudo smartctl -x /dev/sdb1
smartctl 7.2 2020-12-30 r5155 [aarch64-linux-6.1.21-v8+] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke,

Vendor:               TOSHIBA
Product:              External USB 3.0
Revision:             0
Compliance:           SPC-4
User Capacity:        3,000,592,982,016 bytes [3.00 TB]
Logical block size:   512 bytes
Physical block size:  4096 bytes
Logical Unit id:      0x5000000000000001
Serial number:        DA617156C3KD
Device type:          disk
Local Time is:        Sun Sep 10 22:21:32 2023 BST
SMART support is:     Available - device has SMART capability.
SMART support is:     Enabled
Temperature Warning:  Disabled or Not Supported
Read Cache is:        Enabled
Writeback Cache is:   Enabled

SMART Health Status: OK
Current Drive Temperature:     0 C
Drive Trip Temperature:        0 C

Error Counter logging not supported

Device does not support Self Test logging
Device does not support Background scan results logging

Let me format the questions, to avoid prolonged back and forth, answer each question. (crossed out a few after you’ve uploaded SMART results while I was typing:))

  • What disk? SSD/HDD?
  • How is it connected:
    • USB2 or USB3?
      • if USB3 Did you disable UAS?
    • Directly or via HUB?
      • is the hub powered?
      • how is pi powered? Note, pi can only provide 1200mA across all ports.
  • Is this your boot disk?
  • Does your USB disk adapter support SMART?
    • Did you read SMART attributes from the disk? Post them. sudo smartctl -a /dev/sd?
    • Run long smart test on that disk, then, capture smart attributes again
  • What file failed to read?
  • Do you see any other IO related issues in the /var/log/messages? I recommend installing cockpit to view system state in the web ui.

It looks like your enclosure/cable does not support SMART. Connect your disk to the PC with the SATA cable, or use enclosure that supports SMART if you want to capture it on PI.

This is to confirm whether the disk is actually having issues, or the problems are with pi’s USB3 port, UAS, crap cable, or anything else, depending on your answers to the questions above.

  • How is it connected:
    • USB2 or USB3?
      • if USB3 Did you disable UAS?
        NO, i think no
    • Directly or via HUB?
      Directly and with current cables (came with it)
      • is the hub powered?
      • how is pi powered? Note, pi can only provide 1200mA across all ports.
        PSU came with it
  • Is this your boot disk?

USB3 connected! Going to take a look on how the cables are connected, and reboot it! i will give you a feed next minute! the error it gives:
dmesg | grep sdb1 [ 3.417269] sdb: sdb1 [ 10.966277] EXT4-fs (sdb1): warning: mounting fs with errors, running e2fsck is recommended [ 11.182362] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Quota mode: none. [ 56.740319] EXT4-fs error (device sdb1): ext4_lookup:1835: inode #169441650: comm storagenode: iget: checksum invalid [ 56.757629] EXT4-fs error (device sdb1): ext4_lookup:1835: inode #169441650: comm storagenode: iget: checksum invalid

storagewars@raspberrypi:~ $ sudo fsck -p /dev/sdb1
fsck from util-linux 2.36.1
/dev/sdb1 is mounted.
e2fsck: Cannot continue, aborting.

Fstab file with mounting points

/dev/sda1 /home/storagewars/Hds/HD3 ext4 defaults 0 0
/dev/sdb1 /home/storagewars/Hds/HD2 ext4 defaults 0 0

Unmount the drive, it was spinning like crazy! Any suggestions will arrive fluently!

I would connect the disk to USB2 port, UAS is not supported on USB2, and it consumes less power, so you have more remaining power for the drive, reducing the chances of brownout.

If you do connect it to USB3 – use the USB hub with external power, and turn off UAS (You would need to add usb-storage.quirks=AAAA:BBBB:u to /boot/cmdline.txt, where AAAA:BBBB is vendor and device ID obtained from lsusb). USB hub with external power may be a good idea either way.

Then I would get another USB enclosure that does support SMART – there are a few listed on pi’s wiki, for example look for those built on VL817 or VL716 chipsets, or connect it to a pc and get SMART data to confirm whether it was transient issues with usb/uas/lack of power or actual disk bad sector. I bet it’s the former.

Both disks to usb2? Both are on usb3! The disk speed is weak! About 10mb/s on the other hand usb 3 does 100! A 10x! Tomorrow will try USB2, but i don’t think so! I was searching on how to match cheksums from HD and pi!

USB2 supports up to 45MBps of sequential transfers. Storage node is limited by latency, not sequential throughput. You’ll get about 1-2MBps on good days, regardless which port you will use.

However usb3 is more power hungry and more susceptible to interference. If you use usb3 for storage on a raspberry pi — you pretty much have to use powered hub, otherwise you’ll be seeing io and crc errors in the log all over the place. Probably also a good idea to buy a good power supply, and not use the crap it was packaged with. Make sure it can provide 5V at least 3A without browning out. Not many do. I’m using 20W one from this list — it actually provides honest 3A at 5V under fast switching load, I’ve tested. Pies are very sensitive to power quality.

What checksum matching are you taking about?

Why do you must disable UAS? I thought it’s a good thing for external drives…

Few reasons:

  • Very few USB to SATA enclosures/cables/chipsets properly support it. They declare support – but either don’t implement it correctly, or not at all. This results is instability and/or data loss, and/or degraded performance. A lot of cheap cables and enclosures can can be made work by disabling UAS and forcing the USB Mass Storage operation via kernel config (see quirks) STICKY: If you have a Raspberry Pi 4 and are getting bad speeds transferring data to/from USB3.0 SSDs, read this - Raspberry Pi Forums
  • UAS only really helps save 20-30% of CPU utilization on massively fast transfers. Storage node workload is not even close to that to worry about it. And even if it was – the hard drive would have been a bottleneck. To fully take advantage of this you need
    • massive stream of IO
    • fast NVME SSD
    • Separate powered USB hub, because raspberry pi power budged does not support bursty draws from an SSD.
      This is an entirely different scenario.

Generally, with data storage you want to be as conservative as possible. Hence, mass storage driver and USB2 port. It’s more than enough for the intended purpose, and yields much stabler solution.

1 Like

Hmm… maybe this UAS caused a degraded transfer of a large HDD to another, with an Ugreen 50422 case.
A friend tested the same transfer with an old adapter, and the speed was constant, no UAS.
Someone just confirmed me that he had problems with UAS on pi, reseting his device. He disabled it and solved the issue.

I’m pretty sure in this case it’s a data corruption due to insufficient power (two self-powered disks connected to USB3) and/or broken UAS. The solution is to use a hub, and turn off uas.

Will try to connect to usb2 when arrive at home and see if that solves the problem! Thank you for all your help!

1 Like

I realized you are connecting two drives, right? In this case you pretty much have to use powered hub, no matter what. 1200mA pi can provide is not enough for both

Don’t forget to check and repair filesystem once you eliminate the source of corruption.

Even in usb2? Having one on usb3 and the other on usb2 should do the job… i will try to get it to work! Just need to get home!

Yes. Both to usb2 or disable UAS on each disk. Use lsusb to get the list of IDs. On usb2 uas is already disabled.

Furthermore, if you plan to use two drives — you need powered hub. An usb hub that has separate power supply, sufficient to sustain surges from the drives. Like this one.

Raspberry pi can provide 1200mA across all ports in total. Two hard drives can consume more. SSDs — way more. You will keep having disconnects, brownouts and corruptions.

Make sure hubs power supply can provide 5V at high current. Some charging hubs use 12 and use LDO to drop down to 5V. You don’t want these. The one I linked above states BC1.2 charging specification, which implies it has 5V power supply. And Anker is a well known brand of power solution, the power supply they will provide with the hub will be top notch — properly designed, and reliable. You can’t imagine how easy it is to cut corners on a PSu.

Yes, it’s much more complicated that needs to be but hey, it’s a raspberry pi, a prototyping device, not a commercial industrial computer, so you have to figure this all out and make work.

So, this is what you need to do:

  1. Connect hub to power
  2. Connect hub to raspberry’s usb2 port, (or ubs3 port but then you need to configure quirks to disable uas on both disks)
  3. Connect disks to the hub
  4. Fix corruption in the filesystem that has already occurred (fschk)

On Linux i can’t do anything with it, even on USB2! I’m now on Windows using mini tool partition wizard, anyone knows this soft? What should be made? what tests?

Back online on USB2! Now i got misconfig on QUIC! Increased buffer sizes… i’m not able to ping satellites! :frowning: BACK ONLINE :partying_face: :partying_face: :partying_face:

Is the node working over TCP, and only QUIC is not working? You may want to try this: Binding to a specific interface to stabilize QUIC connectivity

But I would not bother. Ignore it. There is almost no traffic over quic anyway.