2

Two external hard drives (USB powered) are initially connected to a Raspberry Pi 4B via the two USB 3.0 ports and they have the following block ids: /dev/sda, /dev/sdb. I used mdadm to create a RADI0 configuration, however, at least once in a day, one of the drives get disconnected (probably). What results is a different id such as /dev/sdc or /dev/sdd.

For testing purposes, I removed the RAID0 configuration and timed how long the block name persists. While simply formatting the hard drive with mkfs.ext4, the /dev/sda device disappeared for some time and reappeared as /dev/sdc.

Restarting the Pi again restores the original ids to the drives.

Initially:

pi@naspi:~ $ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda           8:0    0 465.8G  0 disk 
└─sda1        8:1    0 465.8G  0 part 
sdb           8:16   0 465.8G  0 disk 
└─sdb1        8:17   0 465.8G  0 part

Changes to: (sdb changes to sdc)

pi@naspi:~ $ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda           8:0    0 465.8G  0 disk 
└─sda1        8:1    0 465.8G  0 part 
sdc           8:16   0 465.8G  0 disk 
└─sdc1        8:17   0 465.8G  0 part

How can I fix this without restarting the Pi every time this happens? I do not even know why this is occurring.

(owing to this problem, I can never set up a RAID0 configuration and then share that over my local network as a SAMBA server)

NovoBook
  • 21
  • 2
  • Don't use device node names, they aren't persistent (as you are noticing), particularly if you are using identical hard drives. Use UUIDs -- these refer to partitions not the whole physical device (part vs. disk), but I am pretty sure that's all you really need (I'm guessing the issue is actually the Samba config). You can find them (the UUIDs) with blkid. – goldilocks Sep 22 '20 at 14:17
  • @goldilocks Thanks for replying! Actually, the part which is getting messed up is the RAID0 configuration. Like I said, I'm using 'mdadm' to create the configuration. All the guides I found with respect to setting up a RAID config with mdadm involved using the partition label. Can that be done with UUIDs? Example: mdadm --create --verbose /dev/md0 --level=0 --raid-devices=2 /dev/sda /dev/sdb Is there any way to use UUIDs instead of /dev/sda and /dev/sdb. I believe that would solve my problem. Thank you for responding again! :) – NovoBook Sep 22 '20 at 14:50

2 Answers2

1

Two USB-powered HDDs connected directly to the Pi 4 are ought to be underpowered, you can only get 1.2A from USB, which is 600 mA per HDDs. Most of external HDDs I've seen require 800-1000 mA to work properly.

HDD resets due to unvervoltage is what makes them cycle through device names, but I'll hazard a guess that even if you switch to persistent device names, RAID software will not be happy about devices being randomly reset.

You may want to power your disks separately, or use something similar to this to tweak the Pi USB power limits.

Dmitry Grigoryev
  • 27,928
  • 6
  • 53
  • 144
0

I'm actually not a RAID user, but I was a little bit bothered by the way this issue is ignored in man mdadm, since it is sure to be a common one.

The base block device names in /dev are not persistent, as you have realized. There are, however, a number of ways of using a persistent label that should work in this context. I notice in this U&L post both UUIDs and disk by-id links should work.

UUIDs are associated with filesystem partitions and usually assigned when they are created; if not they can be easily added. In your case this is not so helpful if you need the actual block device.

Disk ids are symbolic link labels in the /dev/disk/by-id directory and they are based on the device serial number, so should be persistent. Here's a Pi with just an SD card in it:

16:21:42root@treehouse>ls -l /dev/disk/by-id
total 0
lrwxrwxrwx 1 root root 13 Aug  2 21:21 mmc-SC32G_0xa51e3b9e -> ../../mmcblk0
lrwxrwxrwx 1 root root 15 Aug  2 21:21 mmc-SC32G_0xa51e3b9e-part1 -> ../../mmcblk0p1
lrwxrwxrwx 1 root root 15 Aug  2 21:21 mmc-SC32G_0xa51e3b9e-part2 -> ../../mmcblk0p2
lrwxrwxrwx 1 root root 15 Aug  2 21:21 mmc-SC32G_0xa51e3b9e-part3 -> ../../mmcblk0p3

Notice the first one (/dev/disk/by-id/mmc-SC32G_0xa51e3b9e) points to the device, /dev/mmcblk0, the others are partitions on it. Since these are symbolic links, they are identical to what they point to.

You can do this kind of thing manually with udev configurations, but there is no need here (it's actually done by udev already).

goldilocks
  • 58,859
  • 17
  • 112
  • 227
  • Ah! This makes sense. I'll try this out. I looked into the post you mentioned, and it seems as though it isn't working properly for that individual. However, I can tinker around a bit. Thanks for pointing me in the proper direction. I'll let you know if this works! – NovoBook Sep 22 '20 at 15:36
  • 1
    I think you also need to look at what is causing * however, at least once in a day, one of the drives get disconnected (probably)* as at some point he RAID will break beyond repair or your machine will be spending all its time rebuilding the RAID esp if these are tin drives. Good way to wear them out... –  Sep 22 '20 at 17:45
  • Excellent point. They are probably dropping out due to insufficient power, we have seen that here multiple times. – goldilocks Sep 22 '20 at 18:48
  • @NovoBook You can also use a volume label, given with mkfs.ext4 -L raid-slave1 /dev/sdb1 (or use e2label) and address it with, e.g. mount LABEL=raid-slave1 /mnt. – Ingo Sep 23 '20 at 08:00
  • Thanks a lot. @Andyroo you were right. Instead of proceeding with the RAID config, I noticed that one of the drives was taking forever to get formatted, to get mounted, etc. So, I disconnected that. I can't have RAID anymore, but, I proceeded to create the SMB server and all. Works absolutely fine. The healthy drive seems to be running non-stop without any problems at all.

    And, I've noted the label information. Will keep that in mind.

    Thanks a lot for your prompt responses, Andyroo, goldilocks ! :)

     – NovoBook Sep 23 '20 at 19:34