I’ve covered the benefits of taking your Raspberry Pi to a solid state drive (SSD) before extensively in this article but in a nutshell you get around a 280% increase in raw throughput and a 1000% increase in 4k random read/writes over a MicroSD card.
That’s fantastic but SSDs have traditionally been very expensive costing you as much as 4+ Raspberry Pis so it seemed silly to use a drive like that as Pi storage. Until now.
That’s right. Thanks to technologies such as 3D NAND flash solid state drives for consumers have now become cheaper than mid-high range MicroSD cards. With 10x the performance of MicroSD cards they are now a no-brainer upgrade for servers or IO intensive Raspberry Pi projects.
Why Choose SSD?
MicroSD cards were not designed to serve as living storage for operating systems. They are designed for devices such as cameras and smart phones that need to write and reliably store data. They’re very good at this and some cards have excellent throughput fast enough to even record 4K video.
But one thing they are not good at is 4k random writes and rewrites. These are small writes throughout a disk and consist of about 25% of all hard drive activity on a computer. Almost every action you take and even routine log file updates trigger these updates so they are very important for performance.
To show you the difference in performance I have developed a benchmark that anyone can run and uploads the results to the site. Click here to see benchmark results.
As you can see all of the top spots in the results are held by solid state drives. Further, solid state drives beat the fastest MicroSD cards by about 300%.
MicroSD performance varied wildly based on quality of the card. But even the very best and most expensive MicroSD cards got absolutely destroyed by even the cheapest solid state drives. This is because SSDs are so fast that they are limited by the speed of the Raspberry Pi’s USB 2.0 ports.
Solid state drives also have very large write caches. This lets your Raspberry Pi push data to the drive and start doing other things and let the drive itself figure out how to organize the data. Much of the throughput and other performance differences in the above chart are because of much better and faster read/write caching.
Which SSD to Buy?
Since all models and types of solid state drives hit the Raspberry Pi’s USB 2.0 transfer speed limit you should buy the cheapest one that fits your needs!
If your Raspberry Pi is mostly stationary it’s easiest and cheapest to just use a normal 2.5″ SATA SSD with a USB adapter. Here’s my recommendation:
The Kingston A400 has been a great drive to use with the Pi for years. It’s reliable, widely available around the world, has low power requirements and performs very well. It’s also very affordable. This drive has been benchmarked over 1000 times at pibenchmarks.com and is the #1 most popular SSD among the Pi community!
Links: AliExpress*, Amazon.com*, Amazon.ca*, Amazon.com.au*, Amazon.co.jp*, Amazon.co.uk*, Amazon.de*, Amazon.es*, Amazon.fr*, Amazon.it*, Amazon.nl*, Amazon.pl*, Amazon.se*, Amazon.sg*
The Kingston A400 drive performs really well in the Raspberry Pi Storage Benchmarks. It’s a great drive and is cheaper than many mid-range MicroSD cards. Another popular choice is the Crucial BX500 which you can sometimes find in a very cheap 120GB version:
The USB 3.1 variant of the StarTech 2.5″ SATA adapter works well with the Pi 4. The USB 3.0 variant doesn’t have firmware updates available and is not recommended.
Links: Amazon.com*, Amazon.ca*, Amazon.com.au*, Amazon.co.jp*, Amazon.co.uk*, Amazon.de*, Amazon.es*, Amazon.fr*, Amazon.it*, Amazon.nl*, Amazon.pl*, Amazon.se*, Amazon.sg*
The 2.5″ SATA to USB adapter above allows us to connect a drive like this to our Pi using USB. There is no power adapter needed as 2.5″ SSDs using adapters are low power and are powered by the Pi through USB. Be careful with enclosures as they tend to take a bit more power (especially for NVMe, see “Power Requirements” section below).
Compact SSD Options
If you move your Pi around a lot or need something more compact there are a couple of options. These eliminate having any extra cables as they plug directly into the USB slot.
The SanDisk Extreme Pro USB SSD is a true solid state drive. This is different than a typical “flash drive” which uses extremely cheap memory and has very low random I/O performance/throughput compared to a real solid state drive. I’ve used both the USB 3.1 and USB 3.2 variants with the Pi successfully and they benchmark very well!
Links: AliExpress*, Amazon.com*, Amazon.ca*, Amazon.com.au*, Amazon.co.jp*, Amazon.co.uk*, Amazon.de*, Amazon.es*, Amazon.fr*, Amazon.it*, Amazon.nl*, Amazon.pl*, Amazon.se*, Amazon.sg*
There are some flash drives (a very small number) that are actually real solid state drives. The SanDisk Extreme Pro is the most popular one on Pi Benchmarks.
You have to be extremely careful when looking for these as 99.9% of flash drives are NOT solid states. The SanDisk Extreme Pro is a true solid state. The cheaper SanDisk Extreme and Extreme Gos are not (needs to be the pro). If you are looking at a USB style drive and they don’t explicitly state it’s a solid state drive then it definitely isn’t!
Other SSD Options
There are many other types of SSDs and storage adapters you can use. For example, there is an older type of drive technology called mini-SATA or mSATA that can be found in a lot of old laptops or bought for very very cheap. I wrote an article on mSATA to USB 3.0 storage adapters here covering these.
There are also extensive M.2 NVME to USB 3.0 and M.2 SATA to USB 3.0 options available as well. You can build a M.2 SATA or M.2 NVME SSD but you need to be careful with which type of M.2 drive you have/buy. They can be B-key, M-key, or M+B keyed. By far the most common and cheap ones are SATA with a B or B+M key. The adapter I have is this one.* For a full overview of different available options check out my Raspberry Pi 4 USB Mass Storage Device Booting Guide where collectively as a community we’ve compiled the best list we can of working and nonworking adapters.
Most types of adapters can be powered by the Pi itself. One notable exception is NVMe enclosures. Throughout the years we have had hundreds of comments from people who had no trouble powering 2.5″ SATA enclosures but couldn’t get a NVMe one to work at all without a powered USB hub.
Very large older 3.5″ SATA drives are known to require more power than the Pi can provide as well as some types of very high performance models that were designed to burn more power to get extra performance gains.
For solid state storage older models of solid state drives (SSDs) are also known to draw more power than their newer counterparts. If you have a drive that you think may fall into this category then definitely be on the lookout for power related issues and extra cautious about your power setup. High end “extreme” performance models also tend to draw more power (Samsung 970 NVMe drives* are some of the fastest in the world but also pretty power hungry for the Pi).
Insufficient Power Symptoms
Symptoms of a lack of power to the drive can include the system only booting sometimes (or not at all) or working for a while and then locking up. Just because the drive boots does not mean it is getting enough power.
Some commenters on previous articles have described this as working fine until there was a sudden spike in CPU usage while they tried to do several things at once (high CPU, accessing storage, activating various hardware all at once) and then they would get a lockup/crash.
This is because the Pi is teetering on the edge of not having enough power and that spike caused it to drop enough where the drive actually lost power (likely only for tiny fractions of a second). This is enough instability to easily cause a crash and worse if it happened to be in the middle of writing something important! Usually nothing will happen other than you’ll have to restart the Pi but because of the risk of data loss and eventually corrupting files. That being said, if you’re particularly unlucky you will have to fsck the drive or potentially even reimage it if fsck is unable to repair the damage!
The best answer is to test for stability. Do this by stressing out the Pi and make sure you are doing activities that stress the CPU and storage at the same time like browsing the web, etc. and if you can do that for a few hours/days without a lockup/crash then you have a stable power setup!
Powered USB Hub Solution
For NVMe enclosures and power hungry drives I personally use this Sabrent powered USB hub and have been recommending it here on the blog for a long time:
The Sabrent powered USB hub delivers a whopping 2.5A of dedicated power for your USB attached devices. This is almost as much as the Pi adapter itself is rated for (3.0A). It will easily power the most thirsty of setups such as NVMe enclosures.
Links: Amazon.com*, Amazon.ca*, Amazon.com.au*, Amazon.co.uk*, Amazon.es*, Amazon.it*, Amazon.nl*, Amazon.pl*, Amazon.se*
Note: Make sure Amazon doesn’t try to take you to the non-powered version and that it’s the one with the AC adapter that plugs in to provide extra power
If this hub isn’t an option for you and you don’t have one already you can try with it then look in the reviews for people saying that it is working with Raspberry Pi. Some powered USB hubs will not play nice with the Pi so before buying one definitely check reviews and do some careful research about what to expect with the Raspberry Pi!
Oversized Power Adapter Solution
This solution will work for setups that are right on the border of having enough and not having enough power. An example would be if you can get a stable boot but are getting occasional lockups/freezes when the power dips just below the threshold it needs.
If you are using a powerful NVMe drive/enclosure combo like the ICY BOX with a high performance Samsung NVMe drive even with the extra 500 mA it will still not even boot. I have had these oversized adapters and they are great but for a very powerful drive/adapter combination you are going to need more than 500 mA.
The CanaKit 3.5A adapter has an extra half an amp (500 mA) of capacity to give some breathing room to your accessories. This is bigger than the official Pi power supply which provides 3.0A.
Links: Amazon.com*, Amazon.ca*, Amazon.com.au*, Amazon.sg*
It’s a lot less extra wires and one less AC plug though if you are right on the border and just need a little bit more. It will depend on your individual drive/adapter combo whether it’s enough or you will have to go full powered USB hub!
In previous articles readers have told me that this specific adapter can be hard to find outside of North America. I tried to link to as many regions as I could find it in but there should be something equivalent in your region (it just likely won’t be specifically designed for the Pi but will be a more generic USB-C charger).
Look for a USB-C power supply rated to supply around 3.5A. 3.0A or lower won’t do much good as that is almost certainly what you already are using. You can use a higher one (at your own risk). The largest one I’ve ever used is my Dell laptop’s 30W USB-C power adapter. It’s probably not a good idea to go too much bigger than this or to even use one this big over the long term (I didn’t, just for occasional testing and as a emergency backup) but USB-C does have some specification improvements related to power management that seem to provide some flexibility here.
The Pi can only pass through a limited amount of extra power. On the Pi 4 this is up to 1.2A of extra power for peripherals (combined) on top of the board’s 3.0A power rating. This is much more than the Pi 2 and some other previous models could do which was only around 0.5A. This also means that getting a power adapter bigger than about 4.2A of rated current is pointless because the Pi won’t allow any more power to flow through to the board to the peripherals through USB anyway even if it’s available.
I’m oversimplifying a little bit to illustrate the point but if you want the full technical details they are available here in the Raspberry Pi USB documentation. The important takeaway is that going much above 3.5-4.0A or so will not actually provide any more power to the Pi because of these limits. If you’ve hit this ceiling and it still isn’t enough you need to go powered USB hub.
I’ve also used ones that charge cell phones to power Pis before and these ones are the most likely to fall into a range close to what the Pi uses. Most of the ones I had around the house for phones were 2.5A (just barely not enough) or 3.0A so it was enough for a backup spare but not enough to provide extra power. Nevertheless, it’s definitely worth it to check what you already have around and see if there are USB-C chargers around to test with!
Note that a powered USB hub essentially bypasses these limits because the power for your peripherals such as your USB storage will come from the AC adapter connection to the powered USB hub instead of the Pi having to provide that power.
Powered USB Hub Troubleshooting
Most hubs including the Sabrent one above can feed back power into the Pi which can cause it to not boot when the power is connected. The reason for this is that the Pi is detecting power and is trying to power on using that source but the current provided isn’t enough for the Pi to actually boot.
The solution to this is to remove the USB hub’s connection from your Pi momentarily and then connect the power. Plug your USB hub back in quickly after reconnecting the Pi’s power (if you have native USB booting set up) and unless you really fumble with reconnecting it you will have it plugged in well before it tries to boot from the SSD!
If this trick doesn’t work then unfortunately you may have a powered USB hub that is not going to work with the Pi. It’s worth checking to see if there are any firmware updates available for your USB hub before you give up on it as some readers have let me know in the comments of previous articles that they were able to get some hubs working after a firmware upgrade!
Benchmarking / Testing Storage
If you’re getting poor performance or just want to verify everything is working correctly you may want to run my storage benchmark with:
sudo curl https://raw.githubusercontent.com/TheRemote/PiBenchmarks/master/Storage.sh | sudo bash
If you search for the model of your drive on Pi Benchmarks you can compare your score with others and make sure the drive is performing correctly!
Create Bootable Drive
Creating your bootable drive is also very easy. You simply image it the same way you would image a blank MicroSD.
I use Win32DiskImager and simply select the USB attached drive just like you would with a MicroSD card and write the image. It’s very easy!
Don’t forget to place an empty “ssh” file in the /boot directory if you want to connect via SSH.
Prevent High CPU Usage
There is an issue where using a solid state drive will cause kworker to consume around 1-10% of your CPU all of the time. This is due to the Pi polling constantly for a Micro SD card to be inserted.
There are two ways to fix this. One is to insert a blank Micro SD card in the Micro SD slot and leave it there all the time. The other is to add a line to your /boot/config.txt. Open up config.txt and add the following:
This option will tell the Pi to only check for a Micro SD card once at bootup. This means if you want to access the card it needs to be in the Pi before it boots up.
I also wrote a complete guide on this very issue that is available here: Fix ~% CPU Usage When SSD Booting with Raspberry Pi
SSD With Raspberry Pi 4
The Raspberry Pi 4 did not originally support USB booting at launch unlike the previous Pi 3 models did. This is because they actually added a physical EEPROM firmware storage chip into the board. Due to this I previously published a workaround for how to set up USB booting using a SD card as a bootloader.
Fortunately the native support has finally been released for USB booting on the Pi 4. I cover how to upgrade to the new firmware and enable native USB booting extensively in my new Raspberry Pi 4 USB Booting Guide (recommended).
If you aren’t sure which SSD / storage adapter to get I have an extensive guide available here: Raspberry Pi 4 / 400 Storage Adapter Guide
SSD With Raspberry Pi 3
Once you have chosen your SSD it is time to configure the Raspberry Pi to boot off USB storage. Fortunately this is extremely simple. To enable booting from USB storage simply boot up your Raspberry Pi and run this command:
echo program_usb_boot_mode=1 | sudo tee -a /boot/config.txt
Alternatively you can put your MicroSD into your computer and open /boot/config.txt and add the line:
Now reboot your Pi and USB boot support will be permanently enabled. This only needs to be done once per Raspberry Pi as the change is permanent.
You may now remove the Micro SD card altogether and plug in your external storage you prepared in the previous section. Power up the Pi and it will boot directly from the USB storage!
SSD with Raspberry Pi 1 / 2 / Zero W
The older Pi family and the Zero / Zero W also support USB booting with a small catch. You still need to have a Micro SD card inserted in the Pi with only one file on (bootcode.bin). This is because these Pis use the older
BCM2835 which is a Micro SD only bootloader.
The good news is that if we put a otherwise blank Micro SD card in there with this file the Pi can boot from USB storage just fine and take full advantage of the increased speed and storage size. Bootcode.bin basically provides the instructions to the Pi telling it how to boot from USB.
First you will format your Micro SD card as FAT32 . FAT32 is the partition type that the Pi bootloader can read and is the same format as the /boot/ partition on a fully imaged Pi card.
Next grab the latest bootcode.bin from the official Raspberry Pi repository at bootcode.bin in official Raspberry Pi GitHub Repository
Copy the bootcode.bin file onto your newly created and otherwise blank FAT32 imaged Micro SD card and then insert the Micro SD card back into the Raspberry Pi.
Now connect your USB storage back to the Pi and power it on. The Pi will boot directly from your USB storage device!
A solid state drive is the biggest upgrade you can give your Pi. When I am configuring my Minecraft Raspberry Pi servers the performance difference is night and day. They boot faster, respond faster and write/read much faster. It’s very difficult to go back to MicroSD after using one of these with your Pi.
I highly recommend running the benchmark for yourself to get an idea of how much performance you can gain!
If you’re looking for a guide on setting up SSD booting with your Pi check out my Pi 4 Native USB Mass Storage Device Booting Guide
If you want to find out the best storage adapters and SSDs for the Pi check out the Best Storage Adapters for the Raspberry Pi 4 / 400
For fixing storage adapters / improving performance with firmware updates: Fixing Storage Adapters for Raspberry Pi with Firmware Updates
If you have one of the new Raspberry Pi 400 kits *then don’t miss my Pi 400 Overclocking and SSD Setup Guide
I tried a 2.5″ usb 3.0 case that does not support uasp
With a mechanical hdd and it was working at last Fine, so the problem is in the uasp cases even if you disable uasp with quirks its like is there somehow,and the hdd goes slow as hell
Is there a another way/ways to disable uasp than the quirks method?
And do you have a list of non uasp usb 3.0, 2.5″/3.5″ cases??
Even the no name ones from AliExpress
To buy some,or do you have any old used non uasp usb 3.0 / 2.5″ cases that you dont use/need anymore to buy them from you??
Those are low power symptoms. Putting a powered USB hub with any of those HDDs should get them working. HDDs draw way too much power. It sounds like with UASP off it is barely able to run in an extremely low power state.
When it’s in low power mode doing things like “ls” will have a several second delay. This is pretty common with HDDs. It’s also common with NVMe SSDs and the symptoms are pretty much the same. It performs extremely slowly. Sometimes you may have to try booting it several times when it’s not getting enough power to get “lucky” and have it boot.
UASP works fine with HDDs and the Pi as long as there is enough power and you aren’t using a incompatible adapter. There are definitely adapters that won’t even work with quirks mode and they are on the list here. If you have an adapter that is known to work it’s almost certainly just power related.
I hate to say it but unless this is an extremely powerful HDD you’re almost certain to be better off with a SD card. If it is an extremely powerful HDD then you also will 100% need a powered USB hub and if it’s not a powerful enough one that you need a powered hub for it’s the type of HDD that is going to probably be 5400 RPM and score lower than a application class (A1) SD card. A $5 2.5″ SSD off eBay used makes infinitely more sense than even buying a powered USB hub for it frankly which will cost you several times that.
I know I said it earlier but this really is the wrong type of technology to pair with the Pi. You’ve been working on it for weeks and are still fighting with it and that really is not a typical experience. You’re doing this on really, *really* hard mode and I think the result will be disappointing as I know the ceiling you can hit on it (4000-5000 and only a few people have ever done that with a HDD) and I can’t calculate any purchase that makes more sense and is a better value than getting the cheapest 2.5″ SSD possible (used if necessary, nothing wrong with that).
Basically if you want to run a HDD definitely use a powered USB hub. HDD is a very bad choice for the Pi for both performance and power. A powered USB hub is pretty much required unless it’s an ultra low power thin 2.5″ SSD meant to go into something like a laptop. I strongly recommend buying something like a Kingston A400 SSD rather than an AliExpress adapter that is known to have issues as you still won’t have enough power. You could even eBay a cheap 2.5″ SSD and it will use literally a fraction of the power of any HDD. Hopefully that helps!
Thanks for the response,i dont think is a power issue,since my 3.5″ case has separate power supply,and the perfomance of normal hdd is very close to ssd,to believe it you need to try it
Since nobody bother to use a normal hdd with the ssds around.
I dont ask for ssds but for 2.5″ cases that don’t support uasp,if you know any brands/models
I don’t know of any adapter that doesn’t intentionally support UASP, no. They’re just all broken and have buggy drivers/firmware. The best way to find them is to buy the cheapest one. This will work anywhere. It works on Amazon. It works on AliExpress. Almost everyone that comes here bought the cheapest adapter and ended up with something like an ELUTENG that barely functions and can’t be updated. It’s finding one that isn’t broken that is hard. It’s generally not cheap either (relatively speaking) as there is a reason these ones end up being $15-$20 instead of $5 and all of that money is going to a better storage controller chipset inside the adapter.
Here’s a notoriously awful one. I completely deleted all of my links to that adapter on this page because so many people bought it (it’s meant to look like a fake StarTech). It’s like $4 and that is way more than it’s worth. There is so much wrong here. They quote the max SATA speed at 600MB/sec for SATA III (it’s 6GB/s). Just buy anything that costs $10 or less pretty much and it will be a giant buggy mess. I almost wonder if yours is a buggy one like this too if it’s actually powered.
I mean I can go connect a HDD right now with a powered USB hub and a StarTech and it will work. Done it lots of times. Here’s a UASP HDD setup I tested in 2019. That’s a Seagate ST500LM000-1EJ162. UASP enabled. Benchmark #22 on the site. One of the oldest there is and I was already doing this successfully. It’s so old I was still using the Raspberry Pi 3 so it worked even last generation. This is definitely not a limitation of HDDs or UASP.
I agree with you though that if it’s a powered enclosure that power isn’t the problem with yours. It must be the enclosure itself. Running a HDD on the Pi in UASP mode is not some unattainable thing though. It just needs a working adapter and yours is not one of them for sure. I definitely understand why you’re reaching the conclusion you are though. If I were to guess you will probably need to go to a non-powered enclosure that works properly with the Pi and use a hub as I don’t know of a lot of options for powered ones that actually work but I’m sure there are some! You are definitely in the most awkward of spots though and it’s rare that I have to recommend buying 2 things (unless you try my cheap SSD option).
Thanks a lot
Is there another way/ways to disable uasp than the quirks method?
There are in fact some other ways! There’s a great guide here.
Unfortunately since this would be the enclosure we’re talking about that has the issues (the page I linked to covered this as well, if this isn’t working and it’s not power then it’s 100% an adapter compatibility issue and it’s very common). That means my $5 SSD trick would still leave you with an enclosure that doesn’t work properly with the Pi.
Definitely let me know what you find. Don’t get me wrong with my replies that I don’t support what you’re trying to do by my responses as I’m only saying what I’m saying to try to give you the best advice and keep you from spending too much money / going down unnecessary rabbit holes (which I fear buying something like a cheap AliExpress adapter intentionally to try to avoid UASP would end up not being productive) but if you are determined to get these working then I’m very curious what effects what you try has on them / if it helps!
I feel like any dollars spent (in order to be used the most productively) should all be toward getting you to a known working adapter and powered USB hub (might not even need the powered USB hub if this ended up just being the enclosure compatibility the whole time). This is just because we 100% know a setup like that will work and not only that you will actually have full UASP speeds and working compatibility. Just turning UASP off is something like a 50% performance penalty even when it’s working properly and not lagging/freezing. Like I said earlier I have literally done exactly what you’re doing many times so there’s nothing inherently wrong with it but it is a trickier setup than most!
The eclosure that really works is an old orico case with the Initio INIC3639 controller that does not support uasp.
But it takes only an 7mm hdd and most of my hdds are 9.5mm i have one 7mm 500gb but its a waste of space i never use more than 10-30gb
Most of the 2.5″ cases i have are known bands
Like logilink,natec,silicon power,etc
Do you have any old 2.5″ hdd at 7200rpm ??
That is interesting actually. I’m familiar with that controller. I for sure understand about the wasted space too. I ran into the same problem with my ICY DOCK 16 drive enclosure where my thicker drives would not go into those 2.5″ bays. I do have some 7200 RPM drives as well. They all work with my StarTech 2.5″ SATA adapter (most of them without a powered USB hub although the 7200 RPM ones are more likely to need it for sure) with UASP enabled basically.
The brand actually isn’t as important as the controller for sure. You can find great enclosures from Orico that all work with UASP 3.0 enabled on here depending on which controller they bought for that adapter/enclosure. I didn’t realize this initially but this article actually doesn’t have my giant list of adapters/enclosures and which ones work (and which ones are known not to work). You should definitely check out that article: Raspberry Pi 4 USB Boot Config Guide for SSD / Flash Drives.
That article has a “Known Working Adapters” section and a “Known Problematic Adapters” section as well as hundreds of comments from others about which ones did / didn’t work. Check the list to make sure yours isn’t already a known bad one for the Pi for sure. It kind of sounds like one that we have seen before. The comments section of that may have your specific enclosure as well (if you start typing in the search box at the top of the comments of your model of enclosure you may very well get a hit).
Sorry for not catching this earlier as I assumed you had seen this list but then I checked and it’s not in this article at all so you may very well have not seen it. There is literally years of work done on which ones to get and which ones not to get (mostly by others leaving comments about their experience, I could not have bought all those enclosures myself). You might be annoyed when you go to that page and see how much more it is of what you are looking for than this article was and then you’ll see why I felt the need to apologize. You could actually use the Problematic Adapters list to do the AliExpress buying strategy we talked about earlier theoretically. Those are on there.
Also check out this article here: Fixing Storage Adapters for Raspberry Pi via Firmware Updates. I don’t know if there will be any available for yours yet but people have fixed this via firmware updates in the past. Hopefully that helps!
I been having this case many years
Unbraded from ebay takes both sata/ide 2.5 hdds, very good quality still works unfortunately its usb 2.0 but im still using it as its quality stuff
With Thick aluminum etc.
There at some good/cheap stuff worth buying you just need to find them.
I want to buy a 7200 rpm 2.5 sata drive they are very cheap in ebay the problem is the health of the drive i asked so many sellers about what is the health of the drives reported with hard disk sentinel
And all they answered that the drives are working,that doesn’t mean anything a drive full of bad sectors can still be working
So do you have any for sale with 100% health
Or degraded health from lifetime use??
Any capacity will do even 60gb/80gb sata/ide at 7200rpm 2.5″ 9.5mm/7mm
Not at the moment, I’m sure you’ll be able to find some though. Definitely let us know how it turns out here!
Hello,i was wrong with the enclosure i have too many and confused.
The eclosure that really works is an old case with the via vli700 controller that does not support uasp.
Do you know any cases/or have links for branded or unbraded cases with via chipsets?
All I have is the list of working adapters and the list of non-working adapters. That is a 3 GB/sec SATA controller. I’ve never heard of anyone intentionally buying one that is 50% slower when there is a list of working ones that cost under $20. That isn’t even a full speed SATA controller (those are 6 GB/sec). There is no reason you would do that other than you basically don’t believe me or my list which is fine. I’m not sure why you came back as you have not followed any of my advice or read my list or you would have solved this problem literally weeks ago. The answer is to just buy a compatible adapter that supports FULL 6 GB/sec UASP speeds. I guess it’s just a question of what your time is worth to you.
A week+ working on a SATA controller trying to buy one that hasn’t been made for years seems… not worth it. A brand new StarTech costs $11.75 man. There’s tons of people in this thread and the other threads confirming it works and I’ve been using that one since like 2018. What are you doing? $11. Your time has to be worth more than this than trying to buy a really old 3 GB/sec SATA controller that I guarantee will cost you MORE than that. For a SLOW adapter! There is no world where I can tell you that is the right decision and makes sense. I would have no credibility if I did that.
UASP is not a drive compatibility issue. Every one of the adapters you have except that one is simply broken / incompatible with the Pi basically. The one that you have working is not ideal. It’s only a 3 GB/sec SATA controller. I honestly would not use that if I had one. It’s incredibly slow and older tech. I’m not sure if you’ll find it for sale as they have a bunch of newer chips like the VL805 and those kind of chips that are newer and full SATA speeds. That older one is several models outdated esssentially and I doubt they’ve made it for years. That is literally obsolete technology by the spec sheet. It’s not even a full SATA 3 controller with 6 GB/sec.
Sorry for being so direct/rude (at least I felt like I was, especially compared to my normal replies) but I promise it’s out of nothing other than I actually do want to help you get A+ results with this. Hopefully that helps!
Im not searching for the same vli700 controller
Im searching for any via vli controller old or new since i use only mechanical drives i dont mind if its a sata 1,2,3 controller since mechanical drives dont go more than 100-120mb/sec,can it be that the raspberry pi4 has via vli controller and cooperate coz of it good with the same brand sata controller?
Do you have in mind any case that uses a resend/new via vli controller to test?
Question: what causes the incompatibilities with the usb sata controllers?
Is it the controller it self?
Is it the raspberry pi4 it self?
Is it the firmware of the controller that needs updating?
Or is it the linux kernel in the OS that needs updating?
Those are actually great questions and I can help a little bit. First to explain the VIA Labs firmware issues with the Pi. These chipsets have long had issues with the Pi but the newer ones like the VL805 are better. Here’s an article talking about when they patched some of these to work with the VL805 a few years back..
One important implication of this is that you should have your Raspberry Pi 4’s firmware updated to the latest. It actually matters for this and you’re right, there are some incompatibilites with the Pi (at the firmware level) and they have fixed some of them before. We’ve actually had some people fix their adapters by updating their Pi firmware before for this reason! This is important and you’re right to be thinking about it this way. Sometimes it’s probably the manufacturers “fault” and other times it was probably the Pi that was implementing things in a weird way. There’s no question the Pi has more trouble with these adapters than any other PC / device I’ve ever tried (and probably you as well).
I have some confirmed tests of people using this. Looks like one person was running an ASMedia adapter and the other person didn’t specify the brand (just the chipset of VL805). I actually don’t have any VL700 ones which is interesting/surprising. The VL805 looks safe / like a winner if you can find one with that chipset and it has already had fixes for the Pi!
Thanks were i can find one vl805 to buy?
Anything on AliExpress??
Or if not do you know the brands of the cases that have vl805 chipsets?
I tried searching AliExpress but almost nobody will tell you on AliExpress what chipset is in it. That’s on purpose. They know it’s not worth returning an item that costs less than $5. If they told you the chipset you would Google it and find out it won’t work so they don’t list them. They’re counting on you buying it and it not being worth returning. The ones under $10 on the first page of AliExpress searching for USB to SATA adapters I recognize about 10 different variants of that tiny little Blue USB to SATA adapter which dozens of people have bought before and it doesn’t work.
If you shop AliExpress with the rule that if they don’t list the chipset there’s a very good reason for that you’ll do a lot better on there.
I actually don’t see many that will work on there. I do at least see an Orico. This one has USB 3.1 Gen2 which those chipsets always seem to work. It’s USB 3.1 Gen1 and older that seem to have trouble a lot of the time.
Definitely let me know what you end up going with and how it turns out as I am curious!
Thanks i will take a look
My orico case with initio inic3639 works ok with my sata drive but the speed does not go below 20mb/sec and i cannot seem to find a firmware for the case/chipset that maybe will correct the speed issue,is there anywere a firmware for inic3639?
Or do you know how to fix this issue?
The case does not support uasp
There are firmware updates out there for the INIC3639
A better place to check though for Orico specifically is here. They have the enclosure firmware update tool there and you just need to check if it matches the model there!
Thanks in google i can find only firmware for the inic3609 chipset
And in the orico site i cant find my case that is the: orico 2578us3 case 🙁
This is the closest I can find. I’m not sure if this is the specific one you have (the transparent Orico USB 3.0 or 3.1 enclosure) but it’s close. This person said the firmware used to be on their site and was removed.
They have a link in their description of that YouTube video you can try. The worst that will happen is if your enclosure isn’t compatible with the tool it will say something like not found or not detected when you try to run it.
I’ve covered doing this before for other enclosures: Fixing Storage Adapters for Raspberry Pi via Firmware Updates. When there isn’t a brand name update available and you flash it with other firmware meant for another device that’s essentially a generic flash. Sometimes it works and sometimes it doesn’t. In rare cases it has made things worse but usually the worst that happens is nothing and sometimes the firmware from other manufacturers is close enough and will have the fixes in it and work.
I think it would probably be worth trying to run the enclosure update tool (maybe both the one from Orico’s site and the one from this YouTube video). This is probably the best shot at getting that one going!
Thanks i will try tomorrow
I havent found any update tool for my enclosure in orico site.
Will let you know anyway james thanks
I found two orico cases with norelsys ns1066
With the stock firmware they did not go more than 20mb/sec with hdparm
I found 2 firmwares here.
I flashed the 2.34 things were better 80mb/sec
I flashed the 2.67 things were excellent 108mb/sec as is the top speed my mechanical hdd can achieve.
The chipset is sata2 to usb3 and without uasp thats all i wanted dated at 2012 the 2.67 firmware is dated at 2014
Now the only thing left is to get a 7200rom 2.5″ hdd ro test
Thanks for your help 🙂
Wow, congratulations, I’m glad your hard work has paid off on this, it looks like you were able to do a successful generic flash on these! You definitely did exactly what I would have tried and joined a pretty small and elite circle of people who have actually fixed these using firmware not meant specifically for that adapter necessarily. Only a handful of others were determined enough to accomplish this (at least that left comments) but it definitely can work and I’m so glad it worked for at least some of yours!
That’s amazing how old the dates are on those firmware versions (including the fixed one). That definitely tells you that these adapters almost certainly sit in warehouses for many, many years before they make their way into our hands. I’m sure you’ve had them for a while but probably not since 2013-2014. Maybe it’s more amazing to me that the firmware has been fixed for that long and if you ordered that same enclosure today it probably still wouldn’t come with that firmware.
Those speeds are very, very good! Definitely let me know how it does when you get your hands on a 7200 RPM drive to test but I’m guessing that it will be fantastic!
Further testing with the natec nkz-0448 3.5″ case with asm235cm chipset loaded the latest firmware from 2017 didn’t improve anything,
I think the sata3 to usb3 chipsets are only meant for ssds in linux arm and windows for mechanical drives,and the uasp support it self in general in linux arm has 0 compatibility with raspberry pi4 for mechanical hdds.
Again who is going to use mechanical drives when ssds are available.
At least they work many times faster than the card reader and not only faster the access/seek time difference its huge.
I tried a couple of years booting from a fast memory card 100read 70write attached in a usb3 card reader in the raspberry pi4 usb3 port
The result was like almost booting from a normal ssd,hdparm speed was 90mb/sec
But the access/seek time like using ssd must have something to do with the nand flash of the
Anyway any news when the raspberry pi5 will be out and hardware will it have??
Tested various usb 3.0 to sata 2.5″ / 3.5″ controllers and mechanical drives.
Asmedia Asm235cm : very slow performance of the hdd drive even with uasp disabled with quirks
Asmedia Asm1153 : very slow performance of the hdd drive even with uasp disabled with quirks
Jmicron jms567: very slow performance of the hdd drive with uasp enabled.
Fast performance If uasp is disabled with quirks
Jmicron jms578: very slow performance of the hdd drive even with uasp disabled with quirks
Initio inic3639 : very slow performance of the hdd drive even with uasp disabled with quirks
Norelsys NS1066: fast perfomance of the hdd drive chipset does not support uasp
Via VLI700 : fast perfomance of the hdd drive chipset does not support uasp
Great results! It looks like the NS1066 and VLI700 are the winners for sure among the ones that don’t support UASP.
Thank you for sharing these! Have you found it worthwhile to use them this way? I take it you are using one of those two as your main setup.
Can you explain to me why all the usb 3.0 cases 3.5″ and 2.5″ if you put mechanical hard disk drive it goes slower than the card reader of Raspberry Pi 3?? And i tried many hdds not just one in different cases always the same result.all cases with different chipsets,asmedia jmicron,via, initio etc.
In sdds they work ok,in normal hdds is a nightmare the delay/lag on the hard drive is very large.eg: tried simple operations like apt upgrade.anyone is aware of this problem?
I forgot to mention i have quirks disabled,hdparm reports descent speeds for a mechanical hdd of 100mb/sec but still the perfomance is like i use a memory card in an sdr12 controller any ideas?
Welcome! You’ve just stumbled across one of the most interesting mysteries that the storage benchmark solved for sure. I can definitely explain what is happening and you’re definitely right to say “whoa, wait a minute here”.
So basically believe it or not the HDD is actually that slow. It has nothing to do with the Pi at all. Recently I opened the benchmark up to PCs and you are right on the money from where it should be. Check out this relatively new brand someone tested on the site here.
This person actually tested 3 HDDs. This is on a full blown PC / laptop so no Pi is involved here. The highest score they were able to achieve was 1986 (which is actually amazing for a HDD and the reason it’s higher than the Pi is probably because there’s no USB involved, and it’s probably why the non-USB drive outperformed his external as well as that one was using USB and was more in line with a Pi’s score). That is basically the maximum performance that a HDD is capable of no matter which platform you are using. You’re right that this result is consistent across the board. It’s basically hitting the IO limits of that technology.
The implications of this are that an average SD card has about the same performance as a HDD. However, an application class SD card (newer technology, these are SD cards that have A1 or A2 on them) is actually faster than a HDD. This was very surprising to me when I made the benchmark years ago. I knew SSDs would be faster because of course that’s newer technology but I would not have imagined that application SD cards are actually faster than HDDs. That actually is the case here outside of some specialty HDDs like 10k-15k HDDs or other specialty ones like SSHDs etc.
Now let’s talk about the hdparm really briefly as well. HDparm measures disk throughput basically. It’s a part of my benchmark as well. What you are seeing is that HDDs are *really* bad at random read/write performance. They’re pretty good at just writing a giant file somewhere which is what hdparm is doing. This is how manufacturers generally mislead consumers on disk performance because that number is ideal and always looks great but doesn’t reflect how it will perform as a OS disk.
The performance for writing a big bulk file is an ideal operation that doesn’t even really happen that often (especially when being used as an OS disk). While HDDs can buffer and write a large file with high speed they are *terrible* at random read/write performance. This is the most important measure for an operating system / application disk.
Your disk is never going to just write big files sequentially like that unless you’re performing a backup operation. What is actually happening is you will have several applications open and they are going to be accessing completely different (random) parts of the disk drive. It turns out HDDs are *awful* at this.
Why? Because they have a giant mechanical arm that has to physically move to another part of the disk for you to read it. It’s a limitation of the technology. SSDs do not have to mechanically move anything to access other parts of the disks and neither do SD cards which is why they outperform a HDD as an operating system / application based disk.
Now keeping in mind that HDD was able to achieve around 1900 points check out what a modern SSD did on my PC here (look at the test numbers as well including DD write for sure): Benchmark #60670. 72,000 vs about 1,900 definitely paints the picture here of how far beyond HDDs modern NVMe SSDs have become for sure. That person’s PC experience is not even on the same planet as mine even if it’s otherwise a fully loaded PC! In fact, if he had an even faster CPU and board than me and was still using this drive he’d still be bottlenecked right at that 2k or so mark and his PC experience would still not be on the same planet of mine because all that nice hardware is bottlenecked by the HDD.
This is why HDDs are often used as longer term storage now because they’re *great* for that. Long term storage is typically *only* accessing in bulk operations like for backup and HDDs thrive here and are cheaper per GB. They’re really bad for an OS drive though including on the Pi but their performance on PC is pretty pathetic as well which is why upgrading it is usually the best upgrade you can give yourself on both Pi and PC platforms (if you’re in a HDD based PC). The mechanical HDD arm can’t be in several places at once which is why for random read/write such as running an OS where it will constantly be touching different log files, reading different processes and config files, etc. the non-mechanical parts such as SD and SSD have the advantage here.
SD cards used to be just as misleading about this. Traditional SD cards were *also* terrible at application / OS performance and the manufacturers used all of the same dirty tricks the SSD/HDD manufacturers use (and in many cases it’s the same company so this makes sense). People caught onto this though when the Pi became popular (as well as other devices standardizing around micro SD cards). They noticed the throughput numbers did not at all reflect reality of how it would perform and thus the “Application Class” for SD cards was created. These are special SD cards that have higher grade memory capable of fast random read/write disk performance meant to be able to handle being ran as an OS drive.
All of your conclusions are definitely correct though I can confirm, hopefully that helps!
Hear that now
Hdparm measures 32mb/sec but i believe it has to do with the i/o,something to do with the usb 3.0 not working correct in linux arm OS with mechanical hdds,the power is enough since the hdd in usb 2.0 takes power from saperate power supply and with 2.5″ and with 3.5″ hdd that goes believe it or not like a medium ssd,i didint see a huge difference paired with my patriot burst ssd(not the elite),i wont belive it if they tell me either.the 2.5 is 5400 rpm the 3.5 is 7200 the more rpm the faster it goes i think,i dont have 10k rpm to test also,there is no bottleneck nothing
The usb 2.0 controller is the JM20337
If i put the same hdd in a usb 2.0 case the mechanical drive goes quite fast,the difference its huge,you should try it.
Mechanical drives works faster in arm just not in usb 3.0 only usb 2.0 they fly even with 30mb/sec the more rpm the faster they go even if the speed is really the same in both hdds the i/o doubles and triples due to the more rpm Nobody must have tried before this
It makes sense who is going to use usb 2.0 when there is 3.0.
In my opinion there is a large bottleneck in the usb3.0 ports of the Rpi people cannot see that when putting an sdd coz ssds use nand flash most thats somehow really fast but still there is slowdown in ssds also means they could go ev n faster,must be a manufacturer defect/design flaw in the ports,controller,pcb etc.i havent got any other brand arm board to test my theory.
Was it so hard to put just a native sata port it will make things a lot easier.
You should check out the HDD section at Pi Benchmarks. There definitely are some people that got them to perform pretty fast including on the Pi.
This one seemed to perform really well. Most of them are under 2000 though including for PCs a lot of the time.
The bottlenecking occurs on the Pi at about a score of ~9000-11000 points. You’ll see a giant “wall” that people hit unless they use something like the Compute Module 4. There definitely is bottlenecking though but with a score of 2000 you’re way, way underneath the ceiling for sure. On a Raspberry Pi 3 the bottleneck drops to about 2500-3000ish even for the best NVMe SSD due to there not being USB 3.0 at all on the Pi 3 (it’s only on the Pi 4).
You can actually see this wall on the top scores page #15. You will notice there are no Raspberry Pi 4’s at all until the 15th page of top. This is where the USB 3.0 bottleneck is for the Pi 4 and then you need to use something that has access to higher version USB ports or can bypass it altogether like the Compute Module 4.
Mechanical drives make a very poor choice as an operating system drive. They’re actually right down there with regular USB flash disks on performance somewhere underneath SD cards. That’s just for an average drive though. Some people on the HDD page have very respectable scores of 5000-7500 which is fantastic. If you already have premium performing drives though then you can absolutely use them and I use the stuff I have available like this all the time. If this is the case I definitely encourage experimenting with them and seeing how fast you can get them!
I would completely recommend against buying or intentionally choosing a HDD particularly for a small and low powered project like the Pi. It’s just a mismatch of eras of tech. You’re pairing something that is large and bulky (especially compared to the Pi itself, or a SSD) that uses very spiky and harsh power curves on a device that has very little power to work with to begin with. Low power usage, small and quiet describe a Raspberry Pi and a SSD but not a HDD. The HDD is the mismatched part here and the ones that are going to score well aren’t meant to be put in anything small or quiet if that makes sense.
If you have a setup that can hit those numbers (and they can be hit on the Pi 4, absolutely, they’re on that page) then it can still be a great setup! It will cost you less than $15 to get a drive that will double or triple the best HDD setup though not to mention they require *much* more power than SSDs (with the exception of very powerful NVMe drives). They’re bulky and have a power curve that is hard on the Pi because going from idle to full spin will pull a heavy “load”.
If you can get them going well definitely post some benchmarks on PiBenchmarks.com as I’d love to observe how you did it as poor performance from HDDs is just completely the norm but there are some outliers for sure! I almost wonder if those people were using powered USB hubs (on some of those big 3.5″ drives they’re using they’d have to be) and you actually are being bottlenecked not by the HDD but by the power usage.
Do you have a powered USB hub by chance?
Thanks a lot,i will try when i have time some tests
One off topic question
Which wifi antenna i should buy:
Tenda O3 or Ubiquity Nanostation Loco M2 ?
I want to use it as a client to take internet from a neighbor 100-150 meter away
The more I think about it the more power makes sense for yours. You said USB 2.0 was working faster right? That is because USB 2.0 can’t use as much power so it’s limiting it and functioning “better” in USB 2.0 mode because the Pi isn’t so far over the power budget. Another way this comes up a lot is if people can only boot with USB 2.0 and power is often the reason as USB 3.0 can use enough power that your Pi can’t even turn on. Definitely let us know what you find!
Now for the other question I will admit I’m biased toward Ubiquity. I actually have a 10G full Unifi network build for my home (has the UDM Pro dual WAN switch, an Aggregator switch and some PoE switches) as well as the WiFi set up. Ubuquiti is actually a Utah company and their headquarters is not very far from me at all. I’m definitely not as familiar with the Tenda but I definitely do love my Ubuiquiti gear!
Thanks again just do a simple test put a mechanical hdd in a usb 3.0 case and boot your Rpi4 from it(the hard drive) with raspbian lite and do a full upgrade
Keep the time needed to finish
Then do the same with the same hdd in a usb 2.0 case in a usb 2.0 port(dont connect the usb 3.0 case in a usb 2.0 port its not going to work like that correct)
And do a full upgrade
Keep the time again and watch how fast it goes when its finish downloading the packages
First make sure the hdd does not have bad sectors as they affect its perfomance
You can check that with the hard disk sentinel utility
Thank you for the article; very helpful.
I purchased the Kingston drive and the StarTech adapter which you recommended.
I am using Arch Linux as the OS. I copied the SD card partitions to the SSD via the ‘dd’ command. After enabling usb-booting and adjusting device
names, the system will boot from the SSD successfully (no SD card installed).
During this setup, I had the rpi-3 connected to a small display. Normally this system runs ‘headless’ so after my initial testing I shutdown, disconnected
the display and re-powered the system. To my surprise, the system does not boot; no activity light (none).
If I reconnect the display and re-power the system, the boot process is successful (no SD card installed).
I am totally stumped; makes no sense to me.
Wow, this is a strange issue that I haven’t heard for a really long time! I had to do some research to try to remember what to do for this. I found a good thread here.
This link is for the Pi 4 but the config.txt parameters should be exactly the same. Basically the two main things to try are setting hdmi_force_hotplug=1 in config.txt or setting a custom screen resolution within raspi-config. This should enable headless GUI booting. I personally haven’t ever had to set this setting for years and years but Arch may still want it (Raspberry Pi OS and Ubuntu both seem to work headless without these).
The other thing to definitely check on this one (especially if it has been running Arch or anything not really Raspberry Pi OS for a while) is that it is extremely unlikely that you have up to date firmware. This is easily upgraded by creating the firmware recovery image SD card with the Raspberry Pi Imager. It only takes seconds to update it once you put the SD card in.
This solution makes perfect sense from your symptoms as we know it has to be display/video related for sure (you diagnosed this well) and those are the main places that can control this kind of behavior. Hopefully that helps and let me know what you find!
Thank you for the response. Here is what I have learned by trial-and-error combined with a small amount of deductive reasoning.
The system will boot successfully (no SD card) if a USB-2 device is also plugged-in. This is why it boots successfully when I am using my
small display. It requires a USB-2 connection which Arch Linux recognizes as a touchscreen/mouse device.
Currently, I am using an extra USB-2 Yubikey as the required US-2 device. With it installed, the system boots successfully.
For the record, the system is a ‘Raspberry Pi 3 B v 1.2’.
The system behaves as if USB is not activated unless a USB-2 device is detected.
With regards to firmware, Arch Linux does include regular firmware updates.
The Raspberry Pi 3 doesn’t have real firmware (really, it’s all on the SD card/SSD on the old ones which doesn’t make it very “firm” at all and is essentially just software at that point). That’s only on the Pi 4 / CM4 / Pi 400. I’m certain that Arch will not install the type of firmware updates I’m talking about but your Pi does *not* have bootloader firmware (and can’t, there’s no EEPROM chip for it on your Pi).
That Pi cannot have the bootloader or the BIOS/UEFI looking startup screen. It doesn’t exist on that one. My instructions were for flashing the EEPROM chip by using a SD card recovery image (not using Raspberry Pi OS) but don’t waste your time on a Pi 3 because it has no EEPROM chip and cannot be updated like this. There’s no chip to flash the firmware onto on older models and you will just use whatever Arch has bundled into their image (used to be a big problem in the Pi 3’s day as we would have to update the SD card images to even get them to boot, very nasty, basically updating files on the raw image with newer “firmware” files).
The Pi 3 is USB 2.0 only and has no bootloader/firmware and they are it’s biggest weaknesses vs. the Pi 4 and why USB booting wasn’t very popular on the Pi 3. Your performance will be capped at about 2500 points on my storage benchmark at pibenchmarks.com over USB 2.0. Over USB 3.0 it’s still bottlenecked at about 8000-9000 points. Even bottlenecked at 2500 points the average SD card is something like 800-1000 points so it’s roughly 2.5x as fast on average even with a Pi 3 so I always USB booted my Pi 3s.
Basically I would do exactly what you are doing despite what I just said (and was during the Pi 3 era). It’s definitely way faster than a SD card still even over USB 2.0. I still have Pi 3s and Pi 2s and Pi 1s (although they don’t get booted as often these days) so I’m not discouraging you from doing this but just explaining the reality and exactly where everything is at on that board revision.
Even the current Pi 4 is bottlenecked *hard* and we are all eagerly awaiting the Pi 5 to give us real NVMe performance because even on current gen it’s bottlenecked. People on the CM4 hit scores of 25000+ easily without the bottlenecks on the Compute Module 4 (CM4) which is kind of a sneak preview for the Pi 5. You can do this by either bypassing the USB ports altogether by using a PCIe 1x NVMe adapter or you can use a IO board with a higher USB revision like USB 3.1/3.2.
Since the Raspberry Pi 3 doesn’t have USB 3.0 ports at all I can’t explain why you’re having to plug in some other USB 2.0 device except that it shouldn’t be happening. The ports are white. There is no USB 3.0 and it’s impossible for it to use it until the Pi 4 basically. It seems like you’re fixing some other USB bug that is occurring by creating this condition (a workaround, but a quirky and unexplained one and not a solution/fix).
I think you may have it as good as it’s getting! If you enable quirks mode you may not have to do that strange bug where you have to plug in another USB 2.0 device (it only has USB 2.0, this shouldn’t have any effect, there’s no USB 3.0 period and everything has to work over 2.0). It sounds like you got it going at least but I’ve never heard of this before and I think quirks mode may be worth a shot!
Hi James, thanks for the tutorial!
I have a Pi 3b+.
I used the image i had already in use and had it up and running from SSD in minutes .
The only thing I can;t get to work is SSH.
I created the ssh file in the boot partition, after rebooting it’s gone, but I can’t SSH to my Pi.
Welcome! Do you happen to have your SD card in while you are still booting by chance? A lot of the time it is because /etc/fstab is pointing to a different partition (like mmcblk0p1 for the boot drive). This is especially likely if you migrated from an earlier OS.
The easiest fix would be to put the SSH file on both the SD card and the SSD’s boot folder. The better fix is to adjust /etc/fstab to boot off of your SSD (something like /dev/sda) instead of the SD card (/dev/mmcblk). You also want to make sure it actually has the openssh package (it usually does but some flavors/images might not) with a sudo apt install openssh-server. Hopefully that helps!
Thanks for the reply!
I was already booting from SSD without SD-card.
After running the install openssh-server command it is now working.
The package was already installed, so not sure what changed 🙂 Anyway, it’s working. Thanks mate.
Now next step is to enable TRIM support!
Excellent, I’m glad to hear you got it up and running! I’m not sure why some of them don’t have it. I feel like it’s some of the “Lite” versions that don’t have it fully enabled and sometimes it’s not even installed. This definitely has caused me headaches before so I figured it was worth a try. I’m glad that tip helped!
It sounds like you’re definitely on the right track here getting the TRIM support enabled. Enjoy and take care!
Thanks for the write-up!
Seems easy to follow -and I would if I had an rpi4 (with USB3.0)
I’ve just fiddled with mounting a (to me) forgotten SSD on my old rpi3, and I am wondering what I will gain, trying to persuade it to boot on the USB attached SSD disk?
I’ve just mounted a fresh but old-ish Crucial 250GB and tested it through the USB ports. Only clocked at ~18MBps . . .
If I get it to boot, wouldn’t it perform just the same as that?
That is actually a great question, and the reason I developed the web site https://pibenchmarks.com. It’s basically a bash script that benchmarks the storage on your Pi to measure differences like this.
The main factors that influence the performance can be the storage adapter (and particularly the quality of the storage controller inside) but the drive performance among the different models of SSDs (A shiny new Samsung 980 Pro vs. a 6-7 year old early generation SSD for example) can also vary widely. It turns out this is even true on the Pi and there are big differences! There can also be differences due to not having UASP support / TRIM support / and some other issues that the benchmark can help identify if you are getting a much lower score than you should be.
The Pi 4 would definitely be faster than the Pi 3 because the Pi 3 did not have USB 3.0 and that is giant bottleneck compared to the performance on a Pi 4 as we’ve seen over the years in the benchmarks (people have tested on all the various older Pi models). In fact, the new and improved USB 3.0 is *still* the bottleneck as I did an article about bypassing it and using a NVMe drive with a Pi 4 Compute Module and even an older Samsung 960 was blowing out 980 Pros that were limited by the USB bus speed.
Even with the USB speed being ultimately the limiting performance factor that doesn’t mean there aren’t differences in the drives and adapters. The performance differences are quite large in a lot of cases. It’s due to other factors such as some drives having more efficient storage controllers or larger caches. Sometimes the silicon on the drive is actually superior like 3D NAND SSD memory vs. older style SSD memory as an example. These types of factors can “make up” for some of the limited bus roughly speaking (offset is probably a better word) when it comes to calculating the performance scores and explain a lot of the differences we can see/identify (still lots of unknown factors as this is ongoing testing/research).
I’d go to pibenchmarks.com and punch in the model of drive you have. Usually someone will have tested that drive or something similar to give you an idea. The 18Mbps is hard to compare (is that DD write speed, etc.) but the script actually tests quite a few of them including that and also IOPS, iozone scores, etc. and breaks them down into a comparable “score”. Hopefully that helps!
Hi James i recently bought the popular Kingston A400 SSD and a 5V 4A power supply. I then followed your USB mass storage boot and it worked very well.
Then when i went to test the storage with the storage benchmark script it crashed and said that an Input/Output error occurred and after that i couldn’t run any commands in the shell (over ssh) it would either say there was an input/output error or the command was not found. So i suspected that it was a power issue, and plugged in a laptop charger with a maximum of 45W output, and it worked fine and the storage script didn’t crash, however after maybe a day of uptime i couldn’t connect to the pi over ssh, i was hosting a paper minecraft server and couldn’t connect to the server via the minecraft client either.
When i try to see dmesg while im running the script i am getting this output just as the benchmarks begin:
[ 1060.466088] WARNING! power/level is deprecated; use power/control instead
[ 1060.875117] st: Version 20160209, fixed bufsize 32768, s/g segs 256
When its either running fio test or iozone test it crashes:
[ 257.968582] WARNING! power/level is deprecated; use power/control instead
[ 258.374455] st: Version 20160209, fixed bufsize 32768, s/g segs 256
[ 268.248145] IPv6: MLD: clamping QRV from 1 to 2!
[ 306.160199] sd 0:0:0:0: [sda] tag#28 uas_eh_abort_handler 0 uas-tag 21 inflight: CMD OUT
[ 306.160222] sd 0:0:0:0: [sda] tag#28 CDB: opcode=0x2a 2a 00 12 84 b6 50 00 00 08 00
[ 306.169844] sd 0:0:0:0: [sda] tag#27 uas_eh_abort_handler 0 uas-tag 20 inflight: CMD OUT
[ 306.169861] sd 0:0:0:0: [sda] tag#27 CDB: opcode=0x2a 2a 00 12 85 d6 60 00 00 08 00
[ 306.171192] sd 0:0:0:0: [sda] tag#26 uas_eh_abort_handler 0 uas-tag 19 inflight: CMD OUT
[ 306.171203] sd 0:0:0:0: [sda] tag#26 CDB: opcode=0x2a 2a 00 12 86 7d f8 00 00 08 00
[ 306.172560] sd 0:0:0:0: [sda] tag#25 uas_eh_abort_handler 0 uas-tag 18 inflight: CMD OUT
[ 306.172572] sd 0:0:0:0: [sda] tag#25 CDB: opcode=0x2a 2a 00 12 84 7c 60 00 00 08 00
[ 306.173914] sd 0:0:0:0: [sda] tag#24 uas_eh_abort_handler 0 uas-tag 17 inflight: CMD OUT
[ 306.173925] sd 0:0:0:0: [sda] tag#24 CDB: opcode=0x2a 2a 00 12 86 4a c0 00 00 08 00
[ 306.175270] sd 0:0:0:0: [sda] tag#23 uas_eh_abort_handler 0 uas-tag 16 inflight: CMD OUT
[ 306.175281] sd 0:0:0:0: [sda] tag#23 CDB: opcode=0x2a 2a 00 12 85 4f 40 00 00 08 00
[ 306.176636] sd 0:0:0:0: [sda] tag#22 uas_eh_abort_handler 0 uas-tag 15 inflight: CMD OUT
[ 306.176649] sd 0:0:0:0: [sda] tag#22 CDB: opcode=0x2a 2a 00 12 85 97 88 00 00 08 00
[ 306.177999] sd 0:0:0:0: [sda] tag#21 uas_eh_abort_handler 0 uas-tag 14 inflight: CMD OUT
[ 306.178009] sd 0:0:0:0: [sda] tag#21 CDB: opcode=0x2a 2a 00 12 86 41 48 00 00 08 00
[ 306.179356] sd 0:0:0:0: [sda] tag#20 uas_eh_abort_handler 0 uas-tag 13 inflight: CMD OUT
[ 306.179366] sd 0:0:0:0: [sda] tag#20 CDB: opcode=0x2a 2a 00 12 86 34 b0 00 00 08 00
[ 306.180719] sd 0:0:0:0: [sda] tag#19 uas_eh_abort_handler 0 uas-tag 10 inflight: CMD OUT
[ 306.180729] sd 0:0:0:0: [sda] tag#19 CDB: opcode=0x2a 2a 00 12 85 20 50 00 00 08 00
[ 306.182075] sd 0:0:0:0: [sda] tag#18 uas_eh_abort_handler 0 uas-tag 9 inflight: CMD OUT
[ 306.182085] sd 0:0:0:0: [sda] tag#18 CDB: opcode=0x2a 2a 00 12 84 7e f8 00 00 08 00
[ 306.183432] sd 0:0:0:0: [sda] tag#17 uas_eh_abort_handler 0 uas-tag 12 inflight: CMD OUT
[ 306.183442] sd 0:0:0:0: [sda] tag#17 CDB: opcode=0x2a 2a 00 12 84 dd b0 00 00 08 00
[ 306.184803] sd 0:0:0:0: [sda] tag#16 uas_eh_abort_handler 0 uas-tag 11 inflight: CMD OUT
[ 306.184814] sd 0:0:0:0: [sda] tag#16 CDB: opcode=0x2a 2a 00 12 85 1f a8 00 00 08 00
[ 306.186163] sd 0:0:0:0: [sda] tag#15 uas_eh_abort_handler 0 uas-tag 8 inflight: CMD OUT
[ 306.186174] sd 0:0:0:0: [sda] tag#15 CDB: opcode=0x2a 2a 00 12 86 29 18 00 00 08 00
[ 306.187518] sd 0:0:0:0: [sda] tag#14 uas_eh_abort_handler 0 uas-tag 7 inflight: CMD OUT
[ 306.187528] sd 0:0:0:0: [sda] tag#14 CDB: opcode=0x2a 2a 00 12 85 c1 f0 00 00 08 00
[ 306.188880] sd 0:0:0:0: [sda] tag#13 uas_eh_abort_handler 0 uas-tag 6 inflight: CMD OUT
[ 306.188891] sd 0:0:0:0: [sda] tag#13 CDB: opcode=0x2a 2a 00 12 85 62 d0 00 00 08 00
[ 306.190242] sd 0:0:0:0: [sda] tag#12 uas_eh_abort_handler 0 uas-tag 5 inflight: CMD OUT
[ 306.190254] sd 0:0:0:0: [sda] tag#12 CDB: opcode=0x2a 2a 00 12 84 8d 40 00 00 08 00
[ 306.191595] sd 0:0:0:0: [sda] tag#11 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD OUT
[ 306.191605] sd 0:0:0:0: [sda] tag#11 CDB: opcode=0x2a 2a 00 12 84 cf 98 00 00 08 00
[ 306.192959] sd 0:0:0:0: [sda] tag#10 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD OUT
[ 306.192970] sd 0:0:0:0: [sda] tag#10 CDB: opcode=0x2a 2a 00 12 85 7b 90 00 00 08 00
[ 306.194315] sd 0:0:0:0: [sda] tag#9 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD OUT
[ 306.194326] sd 0:0:0:0: [sda] tag#9 CDB: opcode=0x2a 2a 00 12 85 63 18 00 00 08 00
[ 306.195679] sd 0:0:0:0: [sda] tag#8 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD OUT
[ 306.195689] sd 0:0:0:0: [sda] tag#8 CDB: opcode=0x2a 2a 00 12 84 3a a8 00 00 08 00
[ 306.197044] sd 0:0:0:0: [sda] tag#7 uas_eh_abort_handler 0 uas-tag 26 inflight: CMD OUT
[ 306.197056] sd 0:0:0:0: [sda] tag#7 CDB: opcode=0x2a 2a 00 12 85 38 b0 00 00 08 00
[ 306.198397] sd 0:0:0:0: [sda] tag#6 uas_eh_abort_handler 0 uas-tag 29 inflight: CMD OUT
[ 306.198407] sd 0:0:0:0: [sda] tag#6 CDB: opcode=0x2a 2a 00 12 84 9b b8 00 00 08 00
[ 306.199758] sd 0:0:0:0: [sda] tag#5 uas_eh_abort_handler 0 uas-tag 28 inflight: CMD OUT
[ 306.199768] sd 0:0:0:0: [sda] tag#5 CDB: opcode=0x2a 2a 00 12 85 36 c0 00 00 08 00
[ 306.201125] sd 0:0:0:0: [sda] tag#4 uas_eh_abort_handler 0 uas-tag 27 inflight: CMD OUT
[ 306.201136] sd 0:0:0:0: [sda] tag#4 CDB: opcode=0x2a 2a 00 12 84 a8 88 00 00 08 00
[ 306.202480] sd 0:0:0:0: [sda] tag#3 uas_eh_abort_handler 0 uas-tag 25 inflight: CMD OUT
[ 306.202490] sd 0:0:0:0: [sda] tag#3 CDB: opcode=0x2a 2a 00 12 85 13 a8 00 00 08 00
[ 306.203898] sd 0:0:0:0: [sda] tag#2 uas_eh_abort_handler 0 uas-tag 24 inflight: CMD OUT
[ 306.203908] sd 0:0:0:0: [sda] tag#2 CDB: opcode=0x2a 2a 00 12 84 f5 d0 00 00 08 00
[ 306.205202] sd 0:0:0:0: [sda] tag#1 uas_eh_abort_handler 0 uas-tag 23 inflight: CMD OUT
[ 306.205213] sd 0:0:0:0: [sda] tag#1 CDB: opcode=0x2a 2a 00 12 85 d1 08 00 00 08 00
[ 306.206559] sd 0:0:0:0: [sda] tag#0 uas_eh_abort_handler 0 uas-tag 22 inflight: CMD OUT
[ 306.206570] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x2a 2a 00 12 84 ae c8 00 00 08 00
[ 306.224267] scsi host0: uas_eh_device_reset_handler start
[ 306.233684] usb 2-1: cmd cmplt err -2
[ 306.243319] usb 2-1: cmd cmplt err -2
[ 306.252935] usb 2-1: cmd cmplt err -2
[ 306.262542] usb 2-1: cmd cmplt err -2
[ 306.272157] usb 2-1: cmd cmplt err -2
[ 306.281765] usb 2-1: cmd cmplt err -2
[ 306.291371] usb 2-1: cmd cmplt err -2
[ 306.300979] usb 2-1: cmd cmplt err -2
[ 306.310587] usb 2-1: cmd cmplt err -2
[ 306.320201] usb 2-1: cmd cmplt err -2
[ 306.329828] usb 2-1: cmd cmplt err -2
[ 306.339443] usb 2-1: cmd cmplt err -2
[ 306.349057] usb 2-1: cmd cmplt err -2
[ 306.358675] usb 2-1: cmd cmplt err -2
[ 306.368293] usb 2-1: cmd cmplt err -2
[ 306.377907] usb 2-1: cmd cmplt err -2
[ 306.387519] usb 2-1: cmd cmplt err -2
[ 306.397133] usb 2-1: cmd cmplt err -2
[ 306.406746] usb 2-1: cmd cmplt err -2
[ 306.416359] usb 2-1: cmd cmplt err -2
[ 306.425972] usb 2-1: cmd cmplt err -2
[ 306.435591] usb 2-1: cmd cmplt err -2
[ 306.445212] usb 2-1: cmd cmplt err -2
[ 306.454832] usb 2-1: cmd cmplt err -2
[ 306.464444] usb 2-1: cmd cmplt err -2
[ 306.474062] usb 2-1: cmd cmplt err -2
[ 306.483679] usb 2-1: cmd cmplt err -2
[ 306.493298] usb 2-1: cmd cmplt err -2
[ 306.502910] usb 2-1: cmd cmplt err -2
[ 311.777310] usb 2-1: Disable of device-initiated U1 failed.
[ 316.897395] usb 2-1: Disable of device-initiated U2 failed.
[ 317.025748] usb 2-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
[ 322.273651] usb 2-1: device descriptor read/8, error -110
[ 322.380600] usb 2-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
[ 327.649640] usb 2-1: device descriptor read/8, error -110
[ 328.013428] usb 2-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
[ 333.281987] usb 2-1: device descriptor read/8, error -110
[ 333.388898] usb 2-1: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
[ 333.517086] scsi host0: uas_eh_device_reset_handler FAILED err -19
[ 333.517107] sd 0:0:0:0: Device offlined - not ready after error recovery
[ 333.517116] sd 0:0:0:0: Device offlined - not ready after error recovery
[ 333.517124] sd 0:0:0:0: Device offlined - not ready after error recovery
[ 333.517132] sd 0:0:0:0: Device offlined - not ready after error recovery
[ 333.517139] sd 0:0:0:0: Device offlined - not ready after error recovery
[ 333.517146] sd 0:0:0:0: Device offlined - not ready after error recovery
[ 333.517154] sd 0:0:0:0: Device offlined - not ready after error recovery
[ 333.517161] sd 0:0:0:0: Device offlined - not ready after error recovery
[ 333.517168] sd 0:0:0:0: Device offlined - not ready after error recovery
[ 333.517176] sd 0:0:0:0: Device offlined - not ready after error recovery
[ 333.517183] sd 0:0:0:0: Device offlined - not ready after error recovery
[ 333.517190] sd 0:0:0:0: Device offlined - not ready after error recovery
[ 333.517198] sd 0:0:0:0: Device offlined - not ready after error recovery
[ 333.517205] sd 0:0:0:0: Device offlined - not ready after error recovery
[ 333.517212] sd 0:0:0:0: Device offlined - not ready after error recovery
[ 333.517220] sd 0:0:0:0: Device offlined - not ready after error recovery
[ 333.517227] sd 0:0:0:0: Device offlined - not ready after error recovery
[ 333.517235] sd 0:0:0:0: Device offlined - not ready after error recovery
[ 333.517242] sd 0:0:0:0: Device offlined - not ready after error recovery
[ 333.517249] sd 0:0:0:0: Device offlined - not ready after error recovery
[ 333.517256] sd 0:0:0:0: Device offlined - not ready after error recovery
[ 333.517264] sd 0:0:0:0: Device offlined - not ready after error recovery
[ 333.517271] sd 0:0:0:0: Device offlined - not ready after error recovery
[ 333.517278] sd 0:0:0:0: Device offlined - not ready after error recovery
[ 333.517286] sd 0:0:0:0: Device offlined - not ready after error recovery
[ 333.517293] sd 0:0:0:0: Device offlined - not ready after error recovery
[ 333.517301] sd 0:0:0:0: Device offlined - not ready after error recovery
[ 333.517308] sd 0:0:0:0: Device offlined - not ready after error recovery
[ 333.517315] sd 0:0:0:0: Device offlined - not ready after error recovery
[ 333.517359] sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x06 cmd_age=58s
[ 333.517372] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x2a 2a 00 12 84 ae c8 00 00 08 00
[ 333.517385] blk_update_request: I/O error, dev sda, sector 310685384 op 0x1:(WRITE) flags 0x8800 phys_seg 1 prio class 0
[ 333.517448] sd 0:0:0:0: rejecting I/O to offline device
[ 333.517463] blk_update_request: I/O error, dev sda, sector 310796168 op 0x1:(WRITE) flags 0x8800 phys_seg 1 prio class 0
[ 333.517490] blk_update_request: I/O error, dev sda, sector 310799392 op 0x1:(WRITE) flags 0x8800 phys_seg 1 prio class 0
[ 333.517516] blk_update_request: I/O error, dev sda, sector 310803728 op 0x1:(WRITE) flags 0x8800 phys_seg 1 prio class 0
[ 333.517541] blk_update_request: I/O error, dev sda, sector 310808384 op 0x1:(WRITE) flags 0x8800 phys_seg 1 prio class 0
[ 333.517566] blk_update_request: I/O error, dev sda, sector 310744664 op 0x1:(WRITE) flags 0x8800 phys_seg 1 prio class 0
[ 333.517590] blk_update_request: I/O error, dev sda, sector 310744800 op 0x1:(WRITE) flags 0x8800 phys_seg 1 prio class 0
[ 333.517618] blk_update_request: I/O error, dev sda, sector 310749160 op 0x1:(WRITE) flags 0x8800 phys_seg 1 prio class 0
[ 333.517654] blk_update_request: I/O error, dev sda, sector 310750240 op 0x1:(WRITE) flags 0x8800 phys_seg 1 prio class 0
[ 333.517686] blk_update_request: I/O error, dev sda, sector 310751128 op 0x1:(WRITE) flags 0x8800 phys_seg 1 prio class 0
[ 333.518017] sd 0:0:0:0: [sda] tag#1 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x06 cmd_age=58s
[ 333.518029] sd 0:0:0:0: [sda] tag#1 CDB: opcode=0x2a 2a 00 12 85 d1 08 00 00 08 00
[ 333.518037] EXT4-fs error (device sda2): __ext4_find_entry:1536: inode #124682: comm dmesg: reading directory lblock 0
[ 333.518067] EXT4-fs warning (device sda2): htree_dirblock_to_tree:1003: inode #126023: lblock 0: comm snapd: error -5 reading directory block
[ 333.518101] sd 0:0:0:0: [sda] tag#2 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x06 cmd_age=58s
[ 333.518119] Buffer I/O error on dev sda2, logical block 0, lost sync page write
[ 333.518121] sd 0:0:0:0: [sda] tag#2 CDB: opcode=0x2a 2a 00 12 84 f5 d0 00 00 08 00
[ 333.518150] sd 0:0:0:0: [sda] tag#3 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x06 cmd_age=58s
[ 333.518160] sd 0:0:0:0: [sda] tag#3 CDB: opcode=0x2a 2a 00 12 85 13 a8 00 00 08 00
[ 333.518189] sd 0:0:0:0: [sda] tag#4 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x06 cmd_age=58s
[ 333.518199] sd 0:0:0:0: [sda] tag#4 CDB: opcode=0x2a 2a 00 12 84 a8 88 00 00 08 00
[ 333.518226] sd 0:0:0:0: [sda] tag#5 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x06 cmd_age=58s
[ 333.518236] sd 0:0:0:0: [sda] tag#5 CDB: opcode=0x2a 2a 00 12 85 36 c0 00 00 08 00
[ 333.518269] sd 0:0:0:0: [sda] tag#6 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x06 cmd_age=58s
[ 333.518279] sd 0:0:0:0: [sda] tag#6 CDB: opcode=0x2a 2a 00 12 84 9b b8 00 00 08 00
[ 333.518305] sd 0:0:0:0: [sda] tag#7 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x06 cmd_age=58s
[ 333.518314] sd 0:0:0:0: [sda] tag#7 CDB: opcode=0x2a 2a 00 12 85 38 b0 00 00 08 00
[ 333.518341] sd 0:0:0:0: [sda] tag#8 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x06 cmd_age=58s
[ 333.518350] sd 0:0:0:0: [sda] tag#8 CDB: opcode=0x2a 2a 00 12 84 3a a8 00 00 08 00
[ 333.518388] sd 0:0:0:0: [sda] tag#9 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x06 cmd_age=58s
[ 333.518398] sd 0:0:0:0: [sda] tag#9 CDB: opcode=0x2a 2a 00 12 85 63 18 00 00 08 00
[ 333.518756] EXT4-fs error (device sda2): ext4_get_inode_loc:4462: inode #2065: block 255: comm journal-offline: unable to read itable block
[ 333.518772] EXT4-fs error (device sda2): ext4_get_inode_loc:4462: inode #2053: block 254: comm systemd-journal: unable to read itable block
[ 333.518779] EXT4-fs warning (device sda2): htree_dirblock_to_tree:1003: inode #126023: lblock 0: comm snapd: error -5 reading directory block
[ 333.518788] EXT4-fs (sda2): previous I/O error to superblock detected
[ 333.518833] Buffer I/O error on dev sda2, logical block 0, lost sync page write
[ 333.518858] EXT4-fs (sda2): previous I/O error to superblock detected
[ 333.518896] Buffer I/O error on dev sda2, logical block 0, lost sync page write
[ 333.518917] EXT4-fs (sda2): I/O error while writing superblock
[ 333.518928] EXT4-fs error (device sda2) in ext4_reserve_inode_write:5751: IO failure
[ 333.518976] Buffer I/O error on dev sda2, logical block 0, lost sync page write
[ 333.518999] EXT4-fs (sda2): I/O error while writing superblock
[ 333.519010] EXT4-fs error (device sda2): ext4_dirty_inode:5953: inode #2053: comm systemd-journal: mark_inode_dirty error
[ 333.519058] Buffer I/O error on dev sda2, logical block 0, lost sync page write
[ 333.519077] EXT4-fs (sda2): I/O error while writing superblock
[ 333.519098] Aborting journal on device sda2-8.
[ 333.519157] Buffer I/O error on dev sda2, logical block 196608, lost sync page write
[ 333.519211] Buffer I/O error on dev sda2, logical block 0, lost sync page write
[ 333.519228] JBD2: Error -5 detected when updating journal superblock for sda2-8.
[ 333.519243] EXT4-fs (sda2): I/O error while writing superblock
[ 333.519256] EXT4-fs error (device sda2): ext4_journal_check_start:83: Detected aborted journal
[ 333.519289] EXT4-fs (sda2): Remounting filesystem read-only
[ 333.519307] EXT4-fs error (device sda2): ext4_get_inode_loc:4462: inode #10304: block 769: comm rs:main Q:Reg: unable to read itable block
[ 333.519432] Buffer I/O error on dev sda2, logical block 0, lost sync page write
[ 333.519507] EXT4-fs (sda2): I/O error while writing superblock
[ 333.519527] EXT4-fs error (device sda2) in ext4_reserve_inode_write:5751: IO failure
[ 333.519632] Buffer I/O error on dev sda2, logical block 0, lost sync page write
[ 333.519695] EXT4-fs (sda2): I/O error while writing superblock
[ 333.519714] EXT4-fs error (device sda2): ext4_dirty_inode:5953: inode #2065: comm journal-offline: mark_inode_dirty error
[ 333.519809] Buffer I/O error on dev sda2, logical block 0, lost sync page write
[ 333.519869] EXT4-fs (sda2): I/O error while writing superblock
[ 333.519898] EXT4-fs error (device sda2) in ext4_dirty_inode:5955: IO failure
[ 333.520372] EXT4-fs error (device sda2) in ext4_reserve_inode_write:5751: IO failure
[ 333.540903] EXT4-fs warning (device sda2): htree_dirblock_to_tree:1003: inode #126023: lblock 0: comm snapd: error -5 reading directory block
Do you have any idea of how i might fix this?
I can for sure tell you what is going on. It’s still power related. It’s basically having trouble reading blocks as you can see it fail over and over.
I can explain why. Even though you connected a 45W power adapter the Pi will only allow 1.2A of power to flow through to your accessories. The 45W adapter bought you a little extra headroom than the regular Pi has which improved the situation but you’re still hitting up against the limits and losing power. It’s only under extreme circumstances like benchmarking but you are bumping right up against the limit (and exceeding it by your log files during FIO).
You can read about this limit here. It’s definitely being artificially restricted. The 1.2A limit is also shared between all 4 USB ports so if you are plugging in other devices that is drawing power and unplugging them (like unplugging your keyboard and ssh’ing in) can sometimes give you enough power to get over the line.
Basically because the Pi won’t pass through the power the solution would for sure in your case be a powered USB hub. This completely frees your Pi’s 1.2A power budget up to plug in everything else and gives your drive reliable power. Do you have one already you could test with by chance?
I’ll try removing my overclocks i have on the pi, and if doesn’t work I will look into buying a powered usb hub, thank you very much, merry christmas! 😀
Merry Christmas to you too! I think you’re in the right track here. You already made a lot of progress squeezing every last ounce of power and putting the oversized power adapter on there and now we just need to overcome the 1.2A ceiling.
Definitely stop by and let us know how it turned out or if you need any more help!