All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adam Goryachev <mailinglists@websitemanagers.com.au>
To: Ron Leach <ronleach@tesco.net>,
	Linux RAID Mailing List <linux-raid@vger.kernel.org>
Subject: Re: Repairing R1: Part tabl, & precise command
Date: Wed, 6 Apr 2016 09:47:52 +1000	[thread overview]
Message-ID: <57044EA8.2010506@websitemanagers.com.au> (raw)
In-Reply-To: <5703E909.8090903@tesco.net>

On 06/04/16 02:34, Ron Leach wrote:
> On 05/04/2016 16:28, Phil Turmel wrote:
>
>>
>> If your array has write-intent bitmaps, use --re-add instead of --add.
>> It'll be quick.  Otherwise just --add and let it rebuild.
>>
>
> Phil, thanks for the advice.
>
> I hit an unexpected problem fixing the partition table on /dev/sdb, 
> the disk that dropped from the Raid1 array.  The problem is caused by 
> /dev/sdb being *smaller* than /dev/sdc (the working array member) - 
> despite the disks being identical products from WD.  gdisk complains 
> that partition 5 (/dev/sdb5), which is to be the Raid1 partner for the 
> LVM containing all our backed up files, is too big (together with the 
> other partitions) for the /dev/sdb disk.
>
> Presumably, raid1 doesn't work if an 'add'ed disk partition is smaller 
> than the existing, running, degraded array?  Am I right in thinking 
> that the LVM won't be able to be carried securely on the underlying md 
> system?  lsdrv is reporting that /dev/md127 has 0 free, so it seems 
> that the LVM is occupying the complete space of /dev/md127, and it 
> must be using the complete space of the underlying /dev/sdc5 because 
> only sdc is active, at the moment (the Raid1 being still degraded).
>
> To protect the LVM, what would be a good thing to do?  Should I define 
> a slightly shorter 'partner' partition on the failed disk (/dev/sdb) - 
> I would think not, but I would welcome advice.
>
> I did think about reducing the size of one of the other partitions on 
> /dev/sdb - there's a swap partition of 2G which could become 1.5G, 
> because there's another 2G on the working disk anyway. Doing that, the 
> partner partitions for the real data could be the same size, though 
> not in exactly the same place on both disks.  I think this might work?
>
> regards, Ron

Hi Ron,

That is one option (reduce the swap partition size). You might also look 
at the mdadm information of the array, generally it is possible to 
create a raid1 array across two devices that are different size, and 
mdadm will automatically ignore the "excess" space of the larger drive.

eg:
sda1 1000M
sdb1 1050M

The disks and partition tables will show both disks 100% full, because 
the partition fills the disk
mdadm will ignore the extra 50M on sdb1 and create a raid1 array of 1000M
LVM (or whatever you put onto the raid1) will show 1000M as the total 
size, and will know nothing about the extra 50M

I think mdadm is silent about size differences if the difference is less 
than 10% (or some other percentage value).

Another concern I have is that the drive has a number of damaged 
sectors, has used up all the "spare" sectors that it has for 
re-allocation, and is now reporting a smaller size because it knows that 
a number of sectors are bad. I don't think drives do this, but it is a 
failed drive, and manufacturers might do some strange things.

Can you provide full output of smartctl, it should show more details on 
the status of the drive, what damage it might have/etc...

Regards,
Adam

-- 
Adam Goryachev Website Managers www.websitemanagers.com.au

  reply	other threads:[~2016-04-05 23:47 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-05  9:14 Repairing R1: Part tabl, & precise command Ron Leach
2016-04-05 11:04 ` Ron Leach
2016-04-05 12:22   ` Ron Leach
2016-04-05 15:28     ` Phil Turmel
2016-04-05 16:34       ` Ron Leach
2016-04-05 23:47         ` Adam Goryachev [this message]
2016-04-06 10:14           ` Ron Leach
2016-04-06 10:31             ` Étienne Buira

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=57044EA8.2010506@websitemanagers.com.au \
    --to=mailinglists@websitemanagers.com.au \
    --cc=linux-raid@vger.kernel.org \
    --cc=ronleach@tesco.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.