Quick query here.
I have a RPi4 with a drive attached and this is used as the media server for my two Vero’s.
It used to be a ext4 formatted mechanical HDD, and with a sata to USB3 converter I was getting transfer speeds from my PC to the network drive up to 80+MB/s. I didn’t get that speed all the time, it was often slower, but typically 50-60MB/s was the norm, with 80+ not being that uncommon and similarly 30-40 also not being unheard of. I figure it depends on the specific part of the spinning disk it was writing to.
Anyway, after many years of use the drive started to die, so I replaced it with a Samsung SSD.
However, transfer speeds have been worse to it than to the mechanical spinner HDD. It is formatted ext4 as well, and got a clean copy of the media from a backup rather than from the dying drive.
Transfer speeds are a pretty standard 33MB/s, with it creeping up to high 30s sometimes, and dropping down to mid-twenties frequently too.
Iperf3 between the RPi4 and desktop are typically in the 700-800Mbps range.
What I’ve tested:
dd if=<large file> of=/dev/null bs=4M
471+1 records in
471+1 records out
1977998862 bytes (2.0 GB, 1.8 GiB) copied, 7.80134 s, 254 MB/s
I then tried: dd if=/dev/zero of=<file on SATA disk> bs=4M count=100
But got a permissions error: “Failed to open : Permission denied”
Given that it is an SSD, I would like to think there are no writing speed issues, but I just don’t understand why the writing speed is generally slower compared to my old mechanical HDD!
And it is physically connected to the Pi4 via a SATA to USB3 adaptor, with a separate power adaptor providing the power. The power adaptor being the front plate of a hdd enclosure that I’ve connected the sata power lead to the drive and the power adaptor to the front plate. I’ve then connected a separate sata data cable to the drive and that to the sata to USB3 adaptor.
This is basically the same power/data set up that I used with the old mechanical HDD.
Q1) - it is showing 6 months worth of logs, so I’m not sure what to look for in there.
-- Logs begin at Fri 2021-05-07 16:00:18 BST, end at Sat 2021-11-06 18:39:18 GMT. --
I’ve got to the end of all 86000 lines of it, and in the dates since I swapped to the SSD there were quite a few entries like this:
Nov 05 23:37:40 raspberrypi kernel: EXT4-fs (sdc2): error count since last fsck: 518
Nov 05 23:37:40 raspberrypi kernel: EXT4-fs (sdc2): initial error at time 1633558047: __ext4_find_entry:1536: inode 156600321
Nov 05 23:37:40 raspberrypi kernel: EXT4-fs (sdc2): last error at time 1633558285: __ext4_find_entry:1536: inode 156600321
similar entries are there for sda2 and sdb2. They are all in white writing in the log, not red. No red errors in recently that I could see.
Q3) - I’ll get a usb linux OS running on my desktop and connect the sdd there and see what the speed I get is. If I recall correctly I did just that when I copied all the data from the backup to the drive and I was getting write speeds that were over 100MB/s I think. But I’ll check again when I can.
Q2) Got this output from the lsusb -v command:
Bus 002 Device 008: ID 152d:0567 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 3.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 9
idVendor 0x152d JMicron Technology Corp. / JMicron USA Technology Corp.
idProduct 0x0567 JMS567 SATA 6Gb/s bridge
bcdDevice 4.25
iManufacturer 1
iProduct 2
iSerial 3
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x002c
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 8mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 15
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0400 1x 1024 bytes
bInterval 0
bMaxBurst 15
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 3.00
bDeviceClass 9 Hub
bDeviceSubClass 0
bDeviceProtocol 3
bMaxPacketSize0 9
idVendor 0x1d6b Linux Foundation
idProduct 0x0003 3.0 root hub
bcdDevice 5.10
iManufacturer 3
iProduct 2
iSerial 1
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x001f
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 12
bMaxBurst 0
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.10
bDeviceClass 9 Hub
bDeviceSubClass 0
bDeviceProtocol 1 Single TT
bMaxPacketSize0 64
idVendor 0x2109 VIA Labs, Inc.
idProduct 0x3431 Hub
bcdDevice 4.21
iManufacturer 0
iProduct 1
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0019
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0001 1x 1 bytes
bInterval 12
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0
bDeviceProtocol 1 Single TT
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0002 2.0 root hub
bcdDevice 5.10
iManufacturer 3
iProduct 2
iSerial 1
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0019
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 12
I presume the first one is the one of interest here, and if I’m understanding the info, it is running USB 3. But I could be mistaken!
I have rebooted it in that time but have no recollection of enabling persistent logs or anything like. For some reason every time recently that I reboot the RPi4 it doesn’t actually restart, and I’ve ended up having to do a new install of Raspbian. No idea why this is happening, but it has happened quite a few times, so I just do everything I can now to not reboot it. The last time this happened was around the start of October which is when I bought the SSD as I rebooted the Pi due to issues with the mechanical HDD, which is when I realised it was dying. But that reboot issue is probably another thing to worry about another time!
sda, sdb and sdc - There is only one SSD attached and that is the only drive attached to the USB ports. The only other drive is the micro sd card that it boots from.
I just did this:
pi@raspberrypi:~ $ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdd 8:48 0 3.7T 0 disk
├─sdd1 8:49 0 16M 0 part
└─sdd2 8:50 0 3.7T 0 part /media/media
mmcblk0 179:0 0 14.4G 0 disk
├─mmcblk0p1 179:1 0 256M 0 part /boot
└─mmcblk0p2 179:2 0 14.2G 0 part /
and the drive is now sdd…
I presume that there is some issue related to this as it appears to be going through all the letters?
The network media drive is Raspbian or Raspberry Pi OS (whichever is the default OS on a RPi) on a RPi4 (I installed the lightest version headless, so no desktop on it), and my two Vero’s which connect to the drive over the network are OSMC. The network RPi4 is directly wired to my router, as is the PC from which I transfer the files to it.
I will test the sd card, but can that be done without switching the Pi off? As every time it doesn’t restart, I have problems getting my library back and have had to do a complete rescan of the library.
On the RPi4, the grab-logs -K-J command says: -bash: grab-logs: command not found
No, the test I suggest would require the Pi to be switched off and actually the card to be overwritten.
To be honest I think you have a fundamental mistake in your setup you should fix that first which might not be related to your SSD but may also relate to it.
E.g. if you have 2 Vero’s connecting to same NAS (your Pi4) it may would make sense to also have a common Mysql Database running on that device. A restart of the NAS should not lead to a loss of Library. Does your Pi4 have a fixed IP allocated?
I was assuming you are running OSMC on the Pi4 as this command is a OSMC specific command.
Actually if you want a identical experience on all devices I might suggest to install OSMC on the Pi4 you always can disable Kodi if you run the Pi4 headless.
I do have a common maria DB database on the Pi4, all of which was setup following the instructions on this page: https://kodi.wiki/view/MySQL
The NAS does have a fixed IP address.
The restart didn’t lose the database as such, it just wouldn’t restart. It would never get to the stage where I could use Putty to login to it remotely. The lights on the Pi wouldn’t show the same activity as when it worked fine, it just seemed as though it has some issue booting up and it stopped. With no monitor attached to view anything, that’s the best explanation I can give. I have half a suspicion there’s some issue with the Pi4 itself, as I recall there being some issues with getting it set up back when i got it that when I googled the issues a lot of people with faulty Pi4s were having the same issues. Hopefully the PI is fine and it is software related though rather than hardware.
It didn’t cross my mind to use OSMC on the NAS. Next time I have the will to go through a whole new setup, I’ll change to that! Would there be a easy and simple way to save my DB so that I can easily set it back up once I change the NAS to OSMC?
At the moment, everything is working, and the only issue I have with my current use is the slower than expected transfer speeds to the SSD. So I can carry on with it as is for a bit.
I’ve currently a close setup: RPI4 as NAS with remote OSMC. Some hints:
RPI4 SD drive: my worth to change the setup to boot on a small SSD instead of SD card, reliability in mind. That will not help here however I agree
You new SSD is connected with SATAtoUSB with a JMicron ship. I encounter many issues with such and was advised to use ASMEDIA for both my boot SSD and data HDD. No more error since.
The UASP mode is not enabled on your SATAtoUSB, that hurts the SSD performance most of the time and may be the source of low transfer (“bInterfaceProtocol 80 Bulk-Only” will be 98 is enabled)
RPI4 headless: same things here, indeed you need to add lines to boot config file to make it happen. I’ve an Ubuntu desktop (!) running on it with VNC, so I should be able to retrieve the line I used for this
OS: Raspberry pi OS or Ubuntu should be preferred in my opinion, but that limited to my opinion. I choose Ubuntu desktop because it’s also a seedbox and torrent client are rarely provided with full options if accessed with web interface. I’ve here both web and full client interface (with VNC) to be able to do all.
NAS speed: I get consistent >90MBps speed and ever more with some samba customization, but be aware one of the last kernel introduced some problem at this level (5.11.0-102x). To be confirmed but it seems to point in this direction. The speed is somehow more variable to be short
Does having one of those small LCD screens directly mounted to the pi board rather than plugged in via the hdmi slot overcome the headless issue?
Well, I have a different SATA to USB adapter, so thought I’d try it to see if it is UASB compatible and if it is a ASMEDIA chip.
Unplugged my pi, switched the SSD sata-USB cable, plugged it all in, powered on the Pi and… won’t boot.
I thought I’d got over that as I’d added a line from one of the other posts to the boot config file, and the Pi had been powered down on a few occasions recently due to some power outages to the socket its plugged into (flipped the circuit breaker in the main electrical box as was doing some work on sockets on the same ring line), and it rebooted up fine. But this time, nope. Not booting. Don’t have a micro-hdmi cable to get it to boot with a monitor attached either.
What line have you added to the boot config file? I can try putting that in and see if that makes it reboot.
With SD card as boot device, no boot with the other adapter? Maybe the entry in the fstab?
USB Data drive should be automatically mounted, I haven’t put mine in the fstab.
For the record here are the adapter I use, could be handy for you or any reader:
-Boot SSD (M.2) connected with Inateck FE2009 (aluminium case)
-Data HDD connected with Ugreen 50422
Both are ASMEDIA/USB3/UASP
About the line added to boot with a 1920x1080 resolution without HDMI connected:
hdmi_force_hotplug=1
hdmi_force_mode=1
hdmi_group=2
hdmi_mode=82
#dtoverlay=vc4-kms-v3d #comment the line if present
A GPIO screen arrived today, so I’ve now got a screen directly mounted to the Pi. Had to get the Pi booted to install it though, but fortunately after playing around for a bit, I got my Pi booted and now with that screen attached, at least I’ll know what’s going on in the future!!
I’ve changed to a different USB-Sata adapter and it is UASP compatible, but it is another JMicron chip. It’s an Orico USB3 hdd/sdd docking station, so external power. Bulky but it does the trick.
I’ll have a play around, and if it doesn’t boot again I’ll use the lines you’ve given.
Hopefully, I’ll get a bit faster now, although some files I’ve transferred recently have been hitting 60+MB/s. If I can get a solid 90+, I’ll be very happy!
And after everything being back working and all good, I moved my RPi back to where it is kept, and now it won’t boot.
My little 3.5" screen is showing the issues but not big enough to show all the line:
“A start job is running for…” and it times out after 90s.
then goes through lots of boot steps
then I’m in emergency mode and cannot open access to console, the root account is locked.
Asks to press enter to continue and it then enters a repeating loop of all this.