linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.com>
To: Veljko <veljko3@gmail.com>, linux-raid@vger.kernel.org
Subject: Re: Linear device of two arrays
Date: Sun, 23 Jul 2017 09:03:33 +1000	[thread overview]
Message-ID: <871sp8xeey.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <cc2ff16e-5368-b828-6acc-6698d6e0b521@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2905 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  reply	other threads:[~2017-07-22 23:03 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-05 15:34 Linear device of two arrays Veljko
2017-07-05 16:42 ` Roman Mamedov
2017-07-05 18:07   ` Wols Lists
2017-07-07 11:07     ` Nix
2017-07-07 20:26     ` Veljko
2017-07-07 21:20       ` Andreas Klauer
2017-07-07 21:53         ` Roman Mamedov
2017-07-07 22:20           ` Andreas Klauer
2017-07-07 22:33           ` Andreas Klauer
2017-07-07 22:52       ` Stan Hoeppner
2017-07-08 10:26         ` Veljko
2017-07-08 21:24           ` Stan Hoeppner
2017-07-09 22:37             ` NeilBrown
2017-07-10 11:03               ` Veljko
2017-07-12 10:21                 ` Veljko
2017-07-14  2:03                   ` NeilBrown
2017-07-14  1:57                 ` NeilBrown
2017-07-14  2:05                   ` NeilBrown
2017-07-14 13:40                   ` Veljko
2017-07-15  0:12                     ` NeilBrown
2017-07-17 10:16                       ` Veljko
2017-07-18  8:58                         ` Veljko
2017-07-20 21:40                           ` Veljko
2017-07-20 22:00                         ` NeilBrown
2017-07-21  9:15                           ` Veljko
2017-07-21 11:37                             ` Veljko
2017-07-22 23:03                               ` NeilBrown [this message]
2017-07-23 10:05                                 ` Veljko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871sp8xeey.fsf@notabene.neil.brown.name \
    --to=neilb@suse.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=veljko3@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).