I have a raid with two USB drives in a mirroring setup. It works pretty well, but the USB bus is pretty flaky and about once a week, for reasons unknown to me (apparently nothing relevant in the logs) a drive will disappear and come back on a different /dev path. Now, mdadm does a great job of recognizing the drives by serial number, so I don't fret over the drive letters much.

The really irritating part for me is that when the drive comes back, it doesn't go into the raid.

    Update Time : Fri Jul 16 12:05:02 2010
          State : clean, degraded
 Active Devices : 1
Working Devices : 1
 Failed Devices : 1
  Spare Devices : 0

           UUID : eac43993:c6a05923:74746b96:dfc4670c (local to host razor)
         Events : 0.468176

    Number   Major   Minor   RaidDevice State
       0       0        0        0      removed
       1       8       81        1      active sync   /dev/sdf1

       2       8       65        -      faulty spare

I can usually get the drive added back with an mdadm --stop /dev/md_d0, and mdadm --assemble /dev/md_d0; sometimes with an mdadm --add /dev/md_d0 /dev/sd1.

If things were written to the disk while the drive was "faulty" though, I get this afterwords.

Number   Major   Minor   RaidDevice State
   2       8       33        0      spare rebuilding   /dev/sdc1
   1       8       49        1      active sync   /dev/sdd1

This is all fine, but rebuilding your raid once a week probably isn't very good for the disks.

What I'm looking for here is either some way to fix this (which I don't think is likely, short of getting it off the USB bus) or some way to turn the raid read-only when a drive disappears. Then I could add it back without having to rebuild. It'd still be flaky, but at least it wouldn't have to rebuild.

I was thinking of using --scan (monitor?) and an event program, but I think it would take quite a while to get right even if I didn't make mistakes.

Any ideas are welcome.

2 Answers 2


Presumably you have a need for these to be external disks? if so then I'd suggest taking these disks out of their USB enclosures and putting them into an eSATA enclosure or two - USB just isn't designed for this kind of thing. If you don't need them to be external then put them on an internal SATA/SAS bus. Either route should make them a lot more stable and won't require software workarounds.

  • Yes. I need for these to be external. I agree that USB is a terrible way to do this and I'm seeing the effects of that. What I'm looking for is a way to make it work anyway. This is not mission critical hardware so if the array goes read-only, it really doesn't matter. But ruining the drives isn't acceptable either.
    – jettero
    Jul 17, 2010 at 11:11
  • 1
    Two eSATA enclosures and a controller will cost you about $150 and save you having to jerry-rig this setup together (if you even can).
    – Chopper3
    Jul 17, 2010 at 11:15
  • 1
    Actually, the enclosures I have already do esata. I think I'll order an esata controller for the rig. You've convinced me.
    – jettero
    Jul 17, 2010 at 11:19
  • Oh great news, I'm sure you'll see much higher performance and availability - good for you :)
    – Chopper3
    Jul 17, 2010 at 11:39

Instead of using /dev/sd[a-z], why you don't use the Linux UUID (Universally Unique Identifier) of the disk. If you plug/unplug a disk it always keep the same UUID.

Look at /dev/disk/by-uuid/ It contains symlinks to the real /dev/sd[a-z] devices.

ls -l /dev/disk/by-uuid
total 0
lrwxrwxrwx 1 root root 10 2010-07-16 09:01 0bef51ef-8a76-4ae5-9e52-7306e57a8c9e -> ../../sda1
lrwxrwxrwx 1 root root 21 2010-07-16 09:01 756eb6b5-865e-419e-b9f6-f061c8473fd4 -> ../../sda2
lrwxrwxrwx 1 root root 21 2010-07-16 09:01 89b89bdb-338b-4a44-86e9-9619d78efac2 -> ../../sdb1

Just change mdadm target devices to /dev/disk/by-uuid/0bef51ef-8a76-4ae5-9e52-7306e57a8c9e (instead of sda1).

  • I use the uuid, never the drive letters. My point was only that the drives disappear from the array and come back as spares. When they do this, they sometimes switch letters, but my mdadm.conf in no way cares about the /dev/ path as it uses the ... actually the serial of the drive rather than the uuid.
    – jettero
    Jul 17, 2010 at 11:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .