Pi 5 HAT: Radxa Penta SATA HAT

[geerlingguy]

Radxa sells an updated version of their Penta SATA HAT for $45, and it includes four SATA drive connectors, plus one edge connector for a 5th drive, 12V power inputs (molex or barrel jack) to power both the drives and the Pi 5 via GPIO, a cable for the 5th drive, an FFC cable to connect the HAT to the Pi 5, and screws for the mounting.

It looks like the SATA controller is a JMB585 PCIe Gen 3x2 SATA controller, so it could benefit from running the Pi 5's PCIe lane at Gen 3.0 speeds (setting dtparam=pciex1_gen=3 in /boot/firmware/config.txt). Radxa sent me a unit for testing.

[geerlingguy]

It's on the site now: https://pipci.jeffgeerling.com/hats/radxa-penta-sata-hat.html

I'll be testing and benchmarking soon!

[geerlingguy]

Some usage notes:

• I had to add dtparam=pciex1 to the /boot/firmware/config.txt to get the HAT to be recognized
• I also could run it at PCIe Gen 3.0 speeds with dtparam=pciex1_gen=3
• To get the HAT to fit on top of the Pi 5 with an active cooler, I had to use needle-nose pliers to break off the tops of the three heat sink fins in the corner closest to the Pi's USB-C port. Otherwise the barrel jack would hit the tops of those heat sink fins, and not make full contact with the GPIO pins
• I could get 800+ MB/sec at Gen 3.0 speeds with an array of four Samsung 8TB QVO SSDs
• I could get 74 MB/sec writing to a RAIDZ1 array over Samba (using OMV)
• I could get 97 MB/sec writing to a RAID 0 array over Samba (using bare Linux)
• I could get 122 MB/sec reading from either array over Samba on the Pi's built-in 1 Gbps network interface
• I could get 240 MB/sec reading from either array over Samba on a HatNET! 2.5G adapter from Pineberry Pi (this was plugged into a HatBRICK! Commander PCIe Gen 2.0 switch, which had one port to the 2.5G HAT, and one to the Radxa Penta SATA HAT
• Idle power consumption for the setup with just the Penta SATA HAT was 6W
• Idle power consumption for the setup including the PCIe switch and 2.5G NIC was 8W
• Power consumption during disk read/write operations over the network was between 8-16W
• Peak power consumption while ZFS was doing some sort of cleanup operation or compression was 24W

[geerlingguy]

One concern could be heating—the JMB585 SATA controller chip hit peaks of 60+°C in my testing:

There is an official fan/OLED board, and that seems like it would be a wise choice for this build. It seems to also require the case, which is also announced but not available anywhere right now. See: https://forum.radxa.com/t/penta-sata-hat-is-now-available/20378

[geerlingguy]

And here's an illustration of the three heatsink fins I had to break off to get the HAT to fit:

[geerlingguy]

I've also been monitoring IRQs and CPU affinity while doing network copies—the writes, specifically—and nothing really jumps out and suggests a bottleneck there (I'm reminded of this old Raspberry Pi linux issue):

This was in the middle of a 50 GB folder copy to a ZFS array. It is averaging 70 MB/sec or so, which is a fair bit less than line speed over the gigabit connection :(

@ThomasKaiser had suggested over in the Radxa forum there could be some affinity issues with networking on the Pi 5, but I don't see that via atop at least...

[geerlingguy]

Monitoring the CPU frequency with vcgencmd measure_clock arm, I do see it dipping down now and then, but mostly staying stable at 2.4 GHz (frequency(0)=2400033792). I will try performance and see if that gives any more consistent write speeds over the network.

I rebooted with force_turbo=1 in /boot/firmware/config.txt, and performed another copy (confirming the frequency was pegged at 2.4 GHz the whole time)... no difference. Still averaging around 70 MB/sec.

Here's htop as well:

And btop since it's pretty and shows similar data to atop in a more pleasing layout:

[geerlingguy]

I also tried NFS instead of Samba, by enabling it, creating a share 'shared', and connecting via Finder at nfs://10.0.2.214/export/shared (I had to glance on the Pi what the exports were, from OMV, with showmount -e localhost).

The copy was more stable around 82 MB/sec, but still no sign of a clear bottleneck in atop.

Unlike Samba, it looked like the nfsd process was pinned to CPU0, and atop showed the IRQ affinity was all on core 0 (which still seemed to have plenty of headroom—IRQ % never topped 20%, and CPU core0 usage stayed under 25% as well (the full CPU never reached above 50% during the copy):

I'm also going to try enabling compression in the ZFS pool, since it seems like I have plenty of CPU on the pi to handle it, and that can actually speed up writing through to the disk (though I don't think that's the bottleneck at all... just something to test that's easy and quick).

Result: ZFS Compression seems to make no difference—there's some more ZFS process CPU consumption, but overall the speed averages around the same 70 MB/sec...

[ThomasKaiser]

What about

echo 1 >/sys/devices/system/cpu/cpufreq/ondemand/io_is_busy
echo default > /sys/module/pcie_aspm/parameters/policy

[geerlingguy]

pi@pi-nas:~ $ sudo su
root@pi-nas:/home/pi# echo 1 >/sys/devices/system/cpu/cpufreq/ondemand/io_is_busy
root@pi-nas:/home/pi# echo default > /sys/module/pcie_aspm/parameters/policy
root@pi-nas:/home/pi# cat /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy
1
root@pi-nas:/home/pi# cat /sys/module/pcie_aspm/parameters/policy
[default] performance powersave powersupersave 

Still seeing the same sporadic performance:

(force_turbo is still set on, and clocks are still measuring at 2.4 GHz.)

[geerlingguy]

More stats on the share from the macOS client:

$ smbutil statshares -a

==================================================================================================
SHARE                         ATTRIBUTE TYPE                VALUE
==================================================================================================
--------------------------------------------------------------------------------------------------
shared                        
                              SERVER_NAME                   10.0.2.214
                              USER_ID                       501
                              SMB_NEGOTIATE                 SMBV_NEG_SMB1_ENABLED
                              SMB_NEGOTIATE                 SMBV_NEG_SMB2_ENABLED
                              SMB_NEGOTIATE                 SMBV_NEG_SMB3_ENABLED
                              SMB_VERSION                   SMB_3.1.1
                              SMB_ENCRYPT_ALGORITHMS        AES_128_CCM_ENABLED
                              SMB_ENCRYPT_ALGORITHMS        AES_128_GCM_ENABLED
                              SMB_ENCRYPT_ALGORITHMS        AES_256_CCM_ENABLED
                              SMB_ENCRYPT_ALGORITHMS        AES_256_GCM_ENABLED
                              SMB_CURR_ENCRYPT_ALGORITHM    OFF
                              SMB_SIGN_ALGORITHMS           AES_128_CMAC_ENABLED
                              SMB_SIGN_ALGORITHMS           AES_128_GMAC_ENABLED
                              SMB_CURR_SIGN_ALGORITHM       AES_128_GMAC
                              SMB_SHARE_TYPE                DISK
                              SIGNING_SUPPORTED             TRUE
                              EXTENDED_SECURITY_SUPPORTED   TRUE
                              LARGE_FILE_SUPPORTED          TRUE
                              FILE_IDS_SUPPORTED            TRUE
                              DFS_SUPPORTED                 TRUE
                              FILE_LEASING_SUPPORTED        TRUE
                              MULTI_CREDIT_SUPPORTED        TRUE
                              MULTI_CHANNEL_SUPPORTED       TRUE
                              SESSION_RECONNECT_TIME        2024-04-03 13:09:10
                              SESSION_RECONNECT_COUNT       1

And Samba version on the Pi:

root@pi-nas:/home/pi# /usr/sbin/smbd --version
Version 4.17.12-Debian

[ThomasKaiser]

Do you do only Finder copies (AKA 'network + storage combined' plus various unknown 'optimization strategies') or have you already tested network and storage individually? A quick iperf3 / iperf3 -R run between Mac and RPi and iozone on your array should be enough.

And for Samba performance I came up with these settings when I wrote the generic 'OMV on SBC' install routine over half a decade ago: https://github.com/armbian/build/blob/e83d1a0eabcc11815945453d58e1b9f4e201de43/config/templates/customize-image.sh.template#L122

[geerlingguy]

I've tested iperf3 on this setup a few times—on the 1 Gbps port, I get 940 Mbps up, 940 Mbps down (doing --reverse), and iozone with a filesize of 10 GB at 1M block size gets me 1.5 GB/sec random read, 1.5 GB/sec random write (obviously affected by caching in the front for ZFS).

I set it to 50 GB to try to bypass more of the cached speed (since this is an 8 GB RAM Pi 5):

	Iozone: Performance Test of File I/O
	        Version $Revision: 3.492 $
		Compiled for 64 bit mode.
		Build: linux-arm 

	Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
	             Al Slater, Scott Rhine, Mike Wisner, Ken Goss
	             Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
	             Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
	             Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
	             Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
	             Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
	             Vangel Bojaxhi, Ben England, Vikentsi Lapa,
	             Alexey Skidanov, Sudhir Kumar.

	Run began: Wed Apr  3 13:27:54 2024

	Include fsync in write timing
	O_DIRECT feature enabled
	Auto Mode
	File size set to 51200000 kB
	Record Size 1024 kB
	Command line used: ./iozone -e -I -a -s 50000M -r 1024k -i 0 -i 2 -f /tank/shared/iozone
	Output is in kBytes/sec
	Time Resolution = 0.000001 seconds.
	Processor cache size set to 1024 kBytes.
	Processor cache line size set to 32 bytes.
	File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride                                    
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
        51200000    1024  1667845  1719853                    1492992  1479166                                                                

[geerlingguy]

Testing from Windows 11 on the same network, reads maxed out at 110 MB/sec, just like on the Mac.

Writes... are getting a consistent 108 MB/sec. (It did get a little more up-and-down around the halfway point, where the below screenshot was taken, but still averages above 105 MB/sec.)

Now I'm shaking my fist strongly at my Mac—why does Apple have to hate GPLv3 so much!? Will try to see if there's a way to see what's going on with macOS Finder. I've heard from @jrasamba that macOS might try using packet signing (see article), which could definitely result in different performance characteristics. Not sure about Windows 11's defaults.

Maybe I have to ditch using my Mac as the 'real world performance' test bed... with other networking stuff it's not an issue. And I know Finder's terrible... I just didn't think it was that terrible. :P

(@jrasamba also suggested watching this video on io_uring with some good general performance tips.)

[ThomasKaiser]

I've heard from @jrasamba that macOS might try using packet signing

You can check with smbstatus on the RPi (should be SMB3_11 and partial(AES-128-GMAC) as protocol revision and signing status with recent macOS versions) or on macOS with smbutil statshares -m /path/to/volume.

As for GPL or not, IIRC Apple always used an SMB client that was derived from *BSD. Only for the SMB server component license issues came into play when Apple replaced Samba with their smbx. But they had another good reason since starting from 10.8 or 10.9 we were able to transfer Mac files flawlessly between Macs via SMB since all the HFS+ attributes were properly mapped via SMB unlike with Samba.

Am about to setup tomorrow a q&d local Netatalk instance on a RPi 5 to restore a TM backup for a colleague on a MacBook to be shipped to her. But since this sounds like fun I might try to do the excercise with Samba instead and see whether the Samba tunables developed over half a decade ago are still important or not. No idea whether spare time allows or not...

[geerlingguy]

@ThomasKaiser - see above (#615 (comment)) — SMB_CURR_SIGN_ALGORITHM AES_128_GMAC does that mean it's enabled?

[ThomasKaiser]

SMB_CURR_SIGN_ALGORITHM AES_128_GMAC does that mean it's enabled?

Yes. Sorry haven't seen the whole comment.

[geerlingguy]

I tried adding server signing = No to the smb.conf on the Pi (and restarting it), and also tried disabling signing on the macOS side:

printf "[default]\nsigning_required=no\n" | sudo tee /etc/nsmb.conf >/dev/null

Doesn't seem to make a difference either in the file copy speed, nor in the smbutil statshares -a output... not sure if it's supposed to disable the signing, or if that's even an accurate reporting.

I also tried setting delayed_ack=0 on the Mac as suggested here:

$ sudo sysctl -w net.inet.tcp.delayed_ack=0
Password:
net.inet.tcp.delayed_ack: 3 -> 0

I unmounted and re-mounted the share, and I'm still seeing the same performance. (So I set it back to 3.)

I'm going to reboot the Pi and Mac entirely and try again. (I had just unmounted the share, restarted smbd on the Pi, and re-mounted the share.)

[geerlingguy]

Reboot changed nothing, so I had a gander at the SMB config documentation, and found the client signing variable might need to be disabled?

client signing = disabled

I re-mounted the share, but it's still showing as AES_128_GMAC for the current algorithm... however, I saw in this Reddit thread that maybe the key is SIGNING_ON, which is not present, which seems to indicate that's not the issue at all, as it's not enabled.

[geerlingguy]

One last little nugget is I was debugging SMB via debug logging (easy enough to enable via OMV's UI), and I noticed there are actually two log files that are being written to when I'm working on my Mac:

-rw-r--r--  1 root root 229K Apr  3 14:51 log.10.0.2.15
...
-rw-r--r--  1 root root 431K Apr  3 14:54 log.mac-studio
-rw-r--r--  1 root root 1.1M Apr  3 14:50 log.mac-studio.old

I wonder if there's any possibility of SMB doing some kind of internal thrashing when it sees my Mac as both IP 10.0.2.15 and local hostname mac-studio?

[ThomasKaiser]

The net.inet.tcp.delayed_ack reference is the 'Internet at work': outdated stuff being copy&pasted over and over again :)

Signing could really be the culprit (just searched through my OMV 'career'). Since I just replaced a M1 Pro MBP with an M3 Air I checked defaults (or what I believe the defaults are):

tk@mac-tk ~ % cat /etc/nsmb.conf 
[default]
signing_required=no

Not required doesn't mean disabled. Unfortunately I'm on macOS 14 for just a couple of days (the lazy guy trying to skip every other macOS release) and am not into all the details yet...

[geerlingguy]

Note that on my Mac, I didn't have anything in place in /etc/nsmb.conf (I had to create the file). And regarding delayed_ack, once I get through anything that makes sense, I enjoy throwing things at the wall and seeing what sticks. And if it doesn't, I can quickly revert ;)

Even with client signing = disabled, nothing changed in the mount, and I don't see SIGNING_ON TRUE, so I would assume it's not on (searching around, it looks like if it's enabled for a share, it will show up like that, and not just SIGNING_SUPPORTED TRUE.

[ThomasKaiser]

I was debugging SMB via debug logging

This can and will harm SMB performance (bitten by this several times). But I guess you also tried it with log settings set to info and 'performance' was the same?

[geerlingguy]

This can and will harm SMB performance (bitten by this several times). But I guess you also tried it with log settings set to info and 'performance' was the same?

I only had it set to debug for about 3 minutes while I was replaying the copy, to get a snapshot of the log. Then set it right back to 'None' (which is the default in OMV). None of the performance data in this issue that I've posted was taken at any time when any smbd logging was enabled.

[geerlingguy]

Shakes fist at Apple:

If I just use Transmit to do an SFTP transfer (file transfer via SSH), I get a solid 115 MB/sec write speed. Going to test a file copy via Terminal straight to the SMB share next, to verify it's not some idiotic issue with Finder itself... stranger things have happened.

[ThomasKaiser]

to verify it's not some idiotic issue with Finder itself

Maybe Apple's most idiotic software piece ever :)

Back in the days when network/storage testing was a huge part of my day job I always used Helios LanTest since being limited in some ways (explained here) showing the performance differences/increases you were aiming for when debugging settings while Windows Explorer and Finder do a lot under the hood that masquerades basic network setting mismatches due to parallelisms and automagically tuned settings like block sizes.

[geerlingguy]

@lolren - Right now, no.

Also Michael Klements did a build with the Penta SATA HAT, and released four variants of his 3D printable case, which is pretty nice looking!

[celly]

@geerlingguy can you verify something I'm seeing?

When plugged in with the 12v DC barrel jack -- The external ATX power supply pins are live.

[geerlingguy]

@celly - Yes, it looks like there's no backfeed protection on the board (tested with my multimeter just now, also confirmed live 12V on the 12V molex pin), so the +12v DC just passes through from the molex to the barrel plug. I would recommend against plugging two power supplies into the board at the same time!

[pfriedel]

Yeah, Radxa specifically calls out that you shouldn't plug the Pi and the HAT in at the same time on their Raspberry Pi page for the product, now. I can't say if that was always there or not, though.

[celly]

@geerlingguy thanks for checking. Wanted to make sure I didn't have a bad board before I plugged drives in.

@pfriedel Yeah, that makes sense. But I'd figure they would have a diode or something on it to protect it from being live. Since, if it is plugged in, even if you think the pi is off, those pins are still live, since they seem to be connected directly to mains.

On a plus side, I may take advantage of this, and use that to power a 12v fan.

Also, sorry to hijack, but this seems to be the best place for info on this right now, so one note about cases. In case anyone finds this and is looking for a case for it, the RADXA official case is not ready for primetime. I have spent the last 3 days fighting it, and each part leads to more headaches and disappointment.

The three major issues are, there is not any clearance for the PCIe cable, so to get the pi and hat in the case, you'll damage the cable. The drive holder is clever, but doesn't allow for any airflow. And, finally, it is designed for the top fan to be from their fan / OLED board, which isn't available.

Not to mention, unless you are very experienced with your 3D printer it is a very tough print, with lots of press fits with zero room for error, and also tabs and screw holes that are not meant for PLA. It really is more meant for mass production and not hobby printing.

If you need a case, I'd start with Michael Klements one from this comment until someone has a chance to tweak the official one.

[pfriedel]

Yeah, for what it's worth I think there are 3 options for connecting a fan:

1. The Molex 12v header - no PWM and maybe a little clunky, but it's pretty straightforward.
2. There's a little JST PH 1.25 5v connector on the bottom of the HAT. I mean, I think it's PH1.25, I'm pretty sure the cable I borrowed the plug from was originally a Horizon Hobby adapter lead, which is PH1.25. Your mileage may vary.
3. Tapping into the official 2x5 JST PHD (I think? I'll have a sample coming in a few days) and pulling one of the GPIO connectors for a 5v PWM fan, if you're feeling fancy.

And boy howdy, you want a fan if you put this in a case for the Pi if nothing else. I stuck a random heatsink from a Pi4 heatsink kit onto the SATA controller chip after chopping off two of the five fins and it just barely clears two 9.5mm drives. Is it doing any good? Who knows, but it probably isn't hurting. On the other hand, I don't think this is a new chip for Radxa, and people have been building NASes off of their hardware for a while, so maybe it just runs warm normally.

Oh, it should also be noted that 15mm drives do not fit. 9.5 is fine if tight. I don't have any 12.5mm drives to test if they fit the spacing or not, unfortunately.

Update: That header is definitely JST PHD 2x5, works like a charm, although the PWM fan I have is about as noisy at 50% as my Noctua 4010 5v is at 100%. I should have figured. And the 5v PWM 4010 is on backorder everywhere. Maybe the 4020 will fit...

[celly]

@pfriedel That is all great information. Thank you so much for taking the time.

Probing the JST and the 10-pin looking for a solid 5v connection is what started all of this for me. The weird fan connector threw me for a loop -- nothing I had fit it. I saw 5v, but not sure how much power I could safely pull through it as I want to use a larger fan.

The 10-pin is interesting since it has I2C and GPIO pass thru on it along with 5v, but I didn't want to tap into that yet, since adding a cheap OLED display is too tempting.

Once I saw that there was 12v on the molex, I decided to go with a 12v 80mm ultra quiet noctua fan that can be run at 1000rpm, and a female to 3-pin molex connector. It is stupid. But it'll be the best type of stupid -- quiet stupid.

The case you designed is awesome -- really great job. I wish you had sent me that case a few hours ago before I decided to design my own.. 🤣 The one I just finished is a bit more "Server" as I decided to not expose the HDMI ports in exchange for a wider case with a larger fan. If it works, I'll share it in the next few days after the fan gets here.

Update: The 12v molex works like a dream for the fan. I published my case using it here -- https://cults3d.com/en/3d-model/gadget/pi-5-nas-tower-for-radxa-hat-with-option-noctua-fan

[Lucius-666]

has anyone checkt the E-Sata for 5v and 12v power?
it would helpful for a HDD Backup drive, 4 bay ssd nas for use

https://www.delock.de/produkt/84402/merkmale.html?g=836

[pfriedel]

I suspect anything that draws more than a few watts (i.e. four 3.5" HDDs) would still need an external power supply. The cable that Radxa provides doesn't appear to be 12v eSATApd compatible, but that doesn't mean the port isn't. It's enough for an external 2.5" HDD, though.

Also, it looks like the SATA Fan/Display HAT is now available from Arace and AliExpress for USD$15-20 if anyone wants to give it a shot. Looking at the pictures of the fan it looks like it's a standard(ish) 3-pin, so it might just be 40mm fan running at full bore which is noisy.

Also Celly's case got linked to from Radxa's wiki, congrats! I redesigned mine to fit an 80mm fan as well because I had to reprint it in PETG after my initial PLA case developed a terminal case of brittleness. I knew PLA wasn't recommended for ITX-based NAS cases, but I figured those get properly hot, while the Pi solution never really gets over 40C, but that's enough. To be fair to PLA I tend to design thin walls that are only 3 perimeters thick, so it doesn't take much for them to lose structural rigidity.

[cassid4]

I'm having an issue with eSATA connection. I first tried to connect the supplied eSATA cable to a 3.5" HDD, however no lights came on, and no disk detected when starting up the Pi. Connecting the drive to one of the regular SATA ports to showed the drive (3.5" drives are too big to fit without extender cables on all but one of the SATA ports). I'm powering with the 12V barrel jack alone (https://www.amazon.ca/100-240V-Adapter-Converter-Transformer-5-5x2-1mm/dp/B07NV6N5QS?ref_=ast_sto_dp is the power supply I'm using which I would think is more than enough). Would it just be a matter of getting a different cable for eSATApd functionality, or as mentioned in the above comment do I need to somehow supply power separately?

I suspect anything that draws more than a few watts (i.e. four 3.5" HDDs) would still need an external power supply. The cable that Radxa provides doesn't appear to be 12v eSATApd compatible, but that doesn't mean the port isn't. It's enough for an external 2.5" HDD, though.

[jack-ma]

The eSATA cable come with the Penta SATA kits of the first batch are 5V only, no 12V power signal. This is changed for the later batches. You can try with another eSATA cable.

[0x800700]

Does someone ever faced that Penta Sata Hat got disconnected time to time, without any reason ?

[Tobiyashi]

My Penta Sata Hat is working with 3 3.5" drives and OMV7 since may without issues.

[Strobeener]

Thinking of going this route, but want to keep system cool. I have the Pi5 already with the active cooler. I am planning to use 4 2.5ssd's i already have. Anyone come up with a 40mm fan mount to attach to side of the drives to mount on top pulling air up from the sata hat board

[maxinmos]

Is it possible to connect two 2.5' HDD directly to this hat?

[pfriedel]

Yeah, any combination of 1, 2, 3 or 4 2.5" drives is fine. One drive is maybe a little unstable, but once you have two they lock in nicely.

[axiopaladin]

HDDs might not fit if they're too thick. You can connect them with 22-pin SATA riser cables if you aren't attached to the idea of mounting them directly overhead the board, though. I have a NAS design in the works that uses those kind of cables with this board and my prototype has been working without issues so far.

[0x800700]

@Tobiyashi, do you have dtparam=pciex1_gen=3 enabled ?

[Tobiyashi]

@0x800700 yes i have.
I followed the user guide from radxa.
this is what i have at the end of my /boot/firmware/config.txt:

[all]
dtparam=pciex1
dtparam=pciex1_gen=3

and i get with the following speeds with the test command:
sudo dd if=/dev/zero of=/dev/sda bs=32M status=progress count=100 oflag=direct

3154116608 bytes (3.2 GB, 2.9 GiB) copied, 12 s, 262 MB/s
100+0 records in
100+0 records out
3355443200 bytes (3.4 GB, 3.1 GiB) copied, 12.771 s, 263 MB/s
So i assume the gen3 is enabled.

And I have a relatively beefy power supply with 120W.

[Hanish94]

Can anyone please tell me if 3.5inch HDD fits in this hat ?? It would be great if you share a picture of how many 3.5 inch HDD gets fits in the right slot.

I am planning to buy this hat but unsure if my existing 3.5inch HDDs would work

Thanks in Advance

[axiopaladin]

Can anyone please tell me if 3.5inch HDD fits in this hat ?? It would be great if you share a picture of how many 3.5 inch HDD gets fits in the right slot.

I am planning to buy this hat but unsure if my existing 3.5inch HDDs would work

Thanks in Advance

You cannot fit any 3.5" drives directly on there, they'll be way too big. You can connect them with SATA cables, though you'll probably have to use an external power supply. Something like this 3.5" drive enclosure could make that easy to build, otherwise you'll have to figure out your own mounting system.

[cassid4]

Technically one 3.5 inch drive works on the hat, but no other can fit due to the spacing. I bought 20 cm sata + power extender cables from AliExpress to fit more 3.5inch drives.

…

On Thu, Oct 24, 2024, 4:20 PM AxioPaladin ***@***.***> wrote: Can anyone please tell me if 3.5inch HDD fits in this hat ?? It would be great if you share a picture of how many 3.5 inch HDD gets fits in the right slot. I am planning to buy this hat but unsure if my existing 3.5inch HDDs would work Thanks in Advance You cannot fit any 3.5" drives directly on there, they'll be way too big. You can connect them with SATA cables, though you'll probably have to use an external power supply. Something like this 3.5" drive enclosure <https://shop.allnetchina.cn/products/internal-sata-iii-drive-enclosure> could make that easy to build, otherwise you'll have to figure out your own mounting system. — Reply to this email directly, view it on GitHub <#615 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAE4KXQRXAFAJGMSLOTNDP3Z5FJCXAVCNFSM6AAAAABFHKRYCCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZWGI3DOOJSGY> . You are receiving this because you commented.Message ID: ***@***.***>

[Hanish94]

Technically one 3.5 inch drive works on the hat, but no other can fit due to the spacing. I bought 20 cm sata + power extender cables from AliExpress to fit more 3.5inch drives.
…
On Thu, Oct 24, 2024, 4:20 PM AxioPaladin @.> wrote: Can anyone please tell me if 3.5inch HDD fits in this hat ?? It would be great if you share a picture of how many 3.5 inch HDD gets fits in the right slot. I am planning to buy this hat but unsure if my existing 3.5inch HDDs would work Thanks in Advance You cannot fit any 3.5" drives directly on there, they'll be way too big. You can connect them with SATA cables, though you'll probably have to use an external power supply. Something like this 3.5" drive enclosure https://shop.allnetchina.cn/products/internal-sata-iii-drive-enclosure could make that easy to build, otherwise you'll have to figure out your own mounting system. — Reply to this email directly, view it on GitHub <#615 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAE4KXQRXAFAJGMSLOTNDP3Z5FJCXAVCNFSM6AAAAABFHKRYCCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZWGI3DOOJSGY . You are receiving this because you commented.Message ID: @.>

Could you please share a picture of your setup if you don’t mind. This might be helpful.

Thanks

[Iliceth]

May I ask a noob question? Just got my pi 5 and the hat and did set the dtparam's.

lspci gives me:

LnkCap: Port #0, Speed 8GT/s, Width x2, ASPM not supported
              ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+
LnkSta: Speed 8GT/s, Width x1 (downgraded)
              TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-

So the speed has indeed gone up, but the width is still downgraded. That's to be expected?

[geerlingguy]

@Iliceth - that just means it's capable of x2, but it's been downgraded to x1 since the port only has one lane.

[HarvsG]

@geerlingguy I noticed in a recent video you're still using this. I've just got one for Xmas.
Two quick questions if you have the time and for others in the thread

1. What software are you using, OMV & ZFS? or just rasbian lite + cli-configured RAID and software?
2. I'm keen to start with two drives and then add more over time as needed anyone know a robust way of doing that, ZFS Z1 + cli?

[axiopaladin]

I use OMV with the ZFS plugin and it works well for me. If you want to expand your ZFS storage one drive at a time, the keyword you should search is "ZFS pool expansion". It's a relatively new feature in openZFS so I'm not sure how much GUI sugar there is for it in OMV yet, but it should be doable from CLI if not.

[geerlingguy]

@HarvsG - OMV certainly works fine, though my setup is completely headless / GUI-less, I run this: https://github.com/geerlingguy/arm-nas