Re: Linear device of two arrays

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jul 21 2017, Veljko wrote:

> Hello Neil,
>
> On 07/21/2017 11:15 AM, Veljko wrote:
>>> On 07/21/2017 12:00 AM, NeilBrown wrote:
>>> Bother.
>>>  mdadm uses "parse_size()" to parse the offset, and this rejects
>>>  "0", which makes sense for a size, but not for an offset.
>>>
>>>  Just leave the "--data-offset=0" out. I checked and that is defintely
>>>  the default for 1.0.
>>
>> Yes, now it works. I was able to create new linear device, restored the
>> saved 3M file and grown xfs. It was really fast and indeed, I'm happy.
>>
>> Thank you very much, Neil!
>
>
> Well, not without problems, it seams.
>
> I was having problem with root partition that was mounted read-only 
> because of some problem with ext4. After fixing that on reboot, I still 
> have extra space that was added with 4 new drives, but there are no md3 
> or md4. I'm mounting this device in fstab with UUID. I noticed that UUID 
> for md4 was the same as md2 before rebooting. But if I use array UUID 
> from examine of md2 (first member of linear raid), I get:
>
>     mount: can't find UUID="24843a41:8f84ee37:869fbe7b:bc953b58"
>
> The one that works and that is in fstab is that one for md2 in by-uuid 
> below.

The UUID you give to mount is the UUID of the filesystem, not of the
device (or array) which stores the filesystem.

One of the problems with use 1.0 metadata (or 0.90) is that the first
component device looks like it contains the same filesystem as the whole
array.   I think this is what is causing your confusion.

>
>
> # cat /proc/mdstat
> Personalities : [raid1] [raid10]
> md2 : active raid10 sda4[4] sdd3[5] sdc3[7] sdb4[6]
>        5761631232 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]
>
> md1 : active raid10 sda3[4] sdd2[5] sdc2[7] sdb3[6]
>        97590272 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]
>
> md0 : active raid1 sda2[2] sdb2[3]
>        488128 blocks super 1.2 [2/2] [UU]
>
>
> No md3 or md4.
>
> Also, no mention of them in mdadm.conf
>
> # definitions of existing MD arrays
>   ARRAY /dev/md/0 metadata=1.2 UUID=e5a17766:b4df544d:c2770d6e:214113ec 
> name=backup1:0
>   ARRAY /dev/md/1 metadata=1.2 UUID=91560d5a:245bbc56:cc08b0ce:9c78fea1 
> name=backup1:1
>   ARRAY /dev/md/2 metadata=1.2 UUID=f6eeaa57:a55f36ff:6980a62a:d4781e44 
> name=backup1:2

This all depends on the details of the particular distro you are using.
You don't, in general, need arrays to be listed in mdadm.conf.  A
particular distro could require it though.

If you run
   mdadm -Es

It will show a sample mdadm.conf which should contain /dev/md/3 - the
new raid10, and /dev/md/4.
You could add those lines to mdadm.conf, then
   mdadm --assemble /dev/md/3
   mdadm --assemble /dev/md/4
and it should get assembled.  Then you should be able to mount the large
filesystem successfully.

NeilBrown

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux