| 1 |
On Thursday 28 May 2015 15:36:04 I wrote: |
| 2 |
> On Thursday 28 May 2015 08:44:27 Rich Freeman wrote: |
| 3 |
> > With an approach like yours, mdadm will attempt to create md1 by |
| 4 |
> > looking ONLY at sda1 and sdb1, and if that pair forms a valid array it |
| 5 |
> > is started, and if not it is not. If you add a new drive to your |
| 6 |
> > system or for whatever reason the kernel/udev rules change a little or |
| 7 |
> > some race condition changes a little then your devices might get |
| 8 |
> > different names, and the array will not be assembled. |
| 9 |
> |
| 10 |
> Hmm. I wonder if that's what's happening to me. Perhaps I'd better adopt |
| 11 |
> UUIDs then, once I work out what mine are. Thanks for the advice. |
| 12 |
|
| 13 |
I've found blkid, which tells me the UUIDs of my various devices, thus: |
| 14 |
|
| 15 |
# blkid /dev/md7 |
| 16 |
/dev/md7: UUID="ycGMf9-hEP2-tjT4-AtkJ-n8RI-pZ44-RqvlEY" |
| 17 |
TYPE="LVM2_member" |
| 18 |
|
| 19 |
Two odd things: |
| 20 |
1. /dev/md7 is the physical volume in which logical volumes are defined, |
| 21 |
so I'm surprised to see TYPE="LVM2_member". |
| 22 |
2. There is no entry corresponding to /dev/md7 under /dev/disk/by-uuid, |
| 23 |
though /dev/md1 and /dev/md5 do have entries there [1]. |
| 24 |
|
| 25 |
To recap, md1 and md5 are raid-1 with metadata < 1.0; they contain extN |
| 26 |
file-systems; md7 has metadata > 1.0 and is a container for 15 logical |
| 27 |
volumes, each of which has an extN file-system and is mounted somewhere |
| 28 |
under / (/usr is not among them; it's in the root file-system). |
| 29 |
|
| 30 |
What should I be doing about this? |
| 31 |
|
| 32 |
[1] For reference, here's the complete list of entries under /dev/disk/by- |
| 33 |
uuid, minus the date etc: |
| 34 |
|
| 35 |
1bb4ba53-677a-4a0e-b737-f3e274f0e71e -> ../../sda2 |
| 36 |
1e20e3e6-e218-485b-b5ff-be85a287e364 -> ../../sda3 |
| 37 |
3a2a6e94-a6f0-4479-ae87-44887946148c -> ../../sda6 |
| 38 |
3befff76-2a0e-49fa-9e6f-2bd0ed73cf31 -> ../../md5 |
| 39 |
43e655ca-a6ef-4931-99b6-3aa2ad6c30cb -> ../../sda8 |
| 40 |
443ae151-0dd5-47a5-9ff6-56cc1027b4f7 -> ../../dm-3 |
| 41 |
47b057a0-3454-4777-8b53-ae5d240b608c -> ../../dm-11 |
| 42 |
47fe6d95-38be-4581-983c-a6368bd085b2 -> ../../dm-6 |
| 43 |
53f0c9c2-c21f-4c26-942d-8760e0697fe4 -> ../../dm-9 |
| 44 |
72b063b2-76bd-4080-aca0-f0109c1ab25d -> ../../dm-4 |
| 45 |
8e2a7e68-ac48-4aa2-9d33-64fd5ffbe759 -> ../../dm-1 |
| 46 |
94612986-3a94-4de0-85b4-3ee822dca0ef -> ../../dm-8 |
| 47 |
96ba30f0-dc69-4083-ab76-df117432bfae -> ../../sdb2 |
| 48 |
b24e7a6f-8f27-420b-aed5-bc1272ba4856 -> ../../dm-12 |
| 49 |
c05dab85-aff2-4402-ae91-7d9097e68206 -> ../../sdb8 |
| 50 |
c1145ff8-f3c0-48ad-a4fe-50330280be69 -> ../../dm-5 |
| 51 |
d0f6c604-2ef9-4812-afbf-5fd6965201e2 -> ../../md1 |
| 52 |
d531c442-7a7f-4595-a4f3-4e7416b3ec47 -> ../../dm-13 |
| 53 |
d66bad37-84d6-4cf7-9414-3d9535261c41 -> ../../dm-2 |
| 54 |
db56ddb3-3106-40fc-8345-d92a2354eb58 -> ../../dm-0 |
| 55 |
e69863b9-8fcd-4d7a-b94f-64baa3a77852 -> ../../sdb3 |
| 56 |
e7ed40e0-826e-406d-bc5a-5e5b9ef37434 -> ../../dm-10 |
| 57 |
ee1f1925-3e2b-4964-9ad5-248fff623b3c -> ../../sdb6 |
| 58 |
ee39723d-b950-4d00-8c8e-9dac75fe478c -> ../../dm-7 |
| 59 |
|
| 60 |
(It would have been nice to sort on the final field but I can't see how to do |
| 61 |
that.) |
| 62 |
|
| 63 |
I assume that the ../../dm-N links refer to the LVs - there are 15 of them. |
| 64 |
md7 is conspicuous by its absence. This seems like a problem to me, and it |
| 65 |
may account for /dev/md7 sometimes not being started at boot time. |
| 66 |
|
| 67 |
-- |
| 68 |
Rgds |
| 69 |
Peter |
Archives