Linux RAID subsystem development
 help / color / mirror / Atom feed
From: Adam Goryachev <adam@websitemanagers.com.au>
To: Ivan Lezhnjov IV <ivan.lezhnjov.iv@gmail.com>
Cc: "linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>
Subject: Re: mdadm: /dev/md0 has been started with 1 drive (out of 2).
Date: Mon, 11 Nov 2013 10:01:08 +1100	[thread overview]
Message-ID: <52801034.5020006@websitemanagers.com.au> (raw)
In-Reply-To: <985D2F3C-9E55-405E-AC95-FF7733599870@gmail.com>

On 08/11/13 17:32, Ivan Lezhnjov IV wrote:
> Hello,
>
> so I've successfully rebuilt the array, added internal bitmap, haven't run any extensive i/o tests but I continued with copying of my data off the old disks and I haven't really noticed a serious impact. This is a first impression only, but so far so good.
>
> Now that I have bitmap I deliberately repeated sleep/resume cycle exactly as it was done the last time that led to array degradation and sure enough the system started up with a degraded array. in fact, it is way more messy this time because both devices were dynamically assigned new /dev/sdx devices: before sleep they were /dev/sdc1 and /dev/sdd1, after resume they became /dev/sdd1 and /dev/sdb1.
I think this is a different issue, raid is not responsible for device 
discovery and mapping to device names. I think udev may provide a 
solution to this where it will ensure each device identified by some 
distinct hardware feature (eg, serial number), will be configured as a 
specific device name. I use this often for ethernet devices, but I 
assume something similar is applicable to disk drives.

> So, I unmounted filesystem on the array, and stopped the array. Then reassembled it, and it looks to be in a good shape. However, I am wondering if this is exactly due to the internal bitmap. Basically what surprised me was that the array was assembled and shown as in sync instantly. Worth noting, I should say that before the laptop went to sleep there were no processes writing to the array disks -- I made sure -- so the data should be consistent on both drives, but as we know from my very first message event count may be still different when upon resume from sleep.
Yes, given that there were no writes to the array, (or minimal writes, 
probably there is always something), then the re-sync would have been so 
quick you would not have noticed it. As mentioned, it can easily be 
completed in a second... for me, it is often a minute or two due to a 
lot of writes happening during the bootup process.
> My question is basically if I'm enjoying the benefits of having 
> internal bitmap or maybe I got lucky and this time event count was the 
> same for both drives? 
The only way to know for sure would be to examine the drives during the 
bootup process before the raid array is assembled....

You might see some information in the logs about the resync.

Regards,
Adam

-- 
Adam Goryachev
Website Managers
P: +61 2 8304 0000                    adam@websitemanagers.com.au
F: +61 2 8304 0001                     www.websitemanagers.com.au


  parent reply	other threads:[~2013-11-10 23:01 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-05  8:41 mdadm: /dev/md0 has been started with 1 drive (out of 2) Ivan Lezhnjov IV
2013-11-05 10:04 ` Adam Goryachev
2013-11-05 10:37   ` Ivan Lezhnjov IV
2013-11-05 11:36     ` Adam Goryachev
2013-11-05 12:02       ` Ivan Lezhnjov IV
2013-11-05 12:31         ` Adam Goryachev
2013-11-06  7:20           ` Ivan Lezhnjov IV
2013-11-06  7:57             ` Adam Goryachev
2013-11-06  9:47               ` Ivan Lezhnjov IV
2013-11-08  6:32                 ` Ivan Lezhnjov IV
2013-11-10 16:01                   ` Ivan Lezhnjov IV
2013-11-10 23:01                   ` Adam Goryachev [this message]
2013-11-10 23:24                     ` Ivan Lezhnjov IV
2013-11-06  8:54         ` Robin Hill
2013-11-05 11:32   ` Ivan Lezhnjov IV
2013-11-05 11:39     ` Adam Goryachev

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=52801034.5020006@websitemanagers.com.au \
    --to=adam@websitemanagers.com.au \
    --cc=ivan.lezhnjov.iv@gmail.com \
    --cc=linux-raid@vger.kernel.org \
    /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