All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Libor Klepáč" <libor.klepac@bcom.cz>
To: linux-lvm@redhat.com
Subject: Re: [linux-lvm] Removing disk from raid LVM
Date: Thu, 12 Mar 2015 22:32:30 +0100	[thread overview]
Message-ID: <7038545.HonGYRpauu@libor-nb> (raw)
In-Reply-To: <21761.51911.473617.291778@quad.stoffel.home>

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

Hello John,

just a quick question, I'll respond on rest later.
I tried to read data from one of old LVs.
To be precise, I tried to read rimage_* directly.

#dd if=vgPecDisk2-lvBackupPc_rimage_0 of=/mnt/tmp/0 bs=10M count=1
1+0 records in
1+0 records out
10485760 bytes (10 MB) copied, 0.802423 s, 13.1 MB/s

# dd if=vgPecDisk2-lvBackupPc_rimage_1 of=/mnt/tmp/1 bs=10M count=1
dd: reading `vgPecDisk2-lvBackupPc_rimage_1': Input/output error
0+0 records in
0+0 records out
0 bytes (0 B) copied, 0.00582503 s, 0.0 kB/s

#dd if=vgPecDisk2-lvBackupPc_rimage_2 of=/mnt/tmp/2 bs=10M count=1
1+0 records in
1+0 records out
10485760 bytes (10 MB) copied, 0.110792 s, 94.6 MB/s

#dd if=vgPecDisk2-lvBackupPc_rimage_3 of=/mnt/tmp/3 bs=10M count=1
1+0 records in
1+0 records out
10485760 bytes (10 MB) copied, 0.336518 s, 31.2 MB/s

As you can see, three parts are ok (and output files do contain *some* data) 
one rimage is missing (well, there is symlink to dm-33 dev node, but it says IO 
error)
Is there a way to kick this rimage out and to use those three remaining rimages?
LV was started 
#lvchange -ay --partial -v vgPecDisk2/lvBackupPc
  Configuration setting "activation/thin_check_executable" unknown.
  PARTIAL MODE. Incomplete logical volumes will be processed.
    Using logical volume(s) on command line
    Activating logical volume "lvBackupPc" exclusively.
    activation/volume_list configuration setting not defined: Checking only host 
tags for vgPecDisk2/lvBackupPc
    Loading vgPecDisk2-lvBackupPc_rmeta_0 table (253:29)
    Suppressed vgPecDisk2-lvBackupPc_rmeta_0 (253:29) identical table reload.
    Loading vgPecDisk2-lvBackupPc_rimage_0 table (253:30)
    Suppressed vgPecDisk2-lvBackupPc_rimage_0 (253:30) identical table 
reload.
    Loading vgPecDisk2-lvBackupPc_rmeta_1 table (253:33)
    Suppressed vgPecDisk2-lvBackupPc_rmeta_1 (253:33) identical table reload.
    Loading vgPecDisk2-lvBackupPc_rimage_1 table (253:34)
    Suppressed vgPecDisk2-lvBackupPc_rimage_1 (253:34) identical table 
reload.
    Loading vgPecDisk2-lvBackupPc_rmeta_2 table (253:35)
    Suppressed vgPecDisk2-lvBackupPc_rmeta_2 (253:35) identical table reload.
    Loading vgPecDisk2-lvBackupPc_rimage_2 table (253:36)
    Suppressed vgPecDisk2-lvBackupPc_rimage_2 (253:36) identical table 
reload.
    Loading vgPecDisk2-lvBackupPc_rmeta_3 table (253:37)
    Suppressed vgPecDisk2-lvBackupPc_rmeta_3 (253:37) identical table reload.
    Loading vgPecDisk2-lvBackupPc_rimage_3 table (253:108)
    Suppressed vgPecDisk2-lvBackupPc_rimage_3 (253:108) identical table 
reload.
    Loading vgPecDisk2-lvBackupPc table (253:109)
  device-mapper: reload ioctl on  failed: Invalid argument


#dmesg says

[747203.140882] device-mapper: raid: Failed to read superblock of device at 
position 1
[747203.149219] device-mapper: raid: New device injected into existing array 
without 'rebuild' parameter specified
[747203.149906] device-mapper: table: 253:109: raid: Unable to assemble 
array: Invalid superblocks
[747203.150576] device-mapper: ioctl: error adding target to table
[747227.051339] device-mapper: raid: Failed to read superblock of device at 
position 1
[747227.062519] device-mapper: raid: New device injected into existing array 
without 'rebuild' parameter specified
[747227.063612] device-mapper: table: 253:109: raid: Unable to assemble 
array: Invalid superblocks
[747227.064667] device-mapper: ioctl: error adding target to table
[747308.206650] quiet_error: 62 callbacks suppressed
[747308.206652] Buffer I/O error on device dm-34, logical block 0
[747308.207383] Buffer I/O error on device dm-34, logical block 1
[747308.208069] Buffer I/O error on device dm-34, logical block 2
[747308.208736] Buffer I/O error on device dm-34, logical block 3
[747308.209383] Buffer I/O error on device dm-34, logical block 4
[747308.210020] Buffer I/O error on device dm-34, logical block 5
[747308.210647] Buffer I/O error on device dm-34, logical block 6
[747308.211262] Buffer I/O error on device dm-34, logical block 7
[747308.211868] Buffer I/O error on device dm-34, logical block 8
[747308.212464] Buffer I/O error on device dm-34, logical block 9
[747560.283263] quiet_error: 55 callbacks suppressed
[747560.283267] Buffer I/O error on device dm-34, logical block 0
[747560.284214] Buffer I/O error on device dm-34, logical block 1
[747560.285059] Buffer I/O error on device dm-34, logical block 2
[747560.285633] Buffer I/O error on device dm-34, logical block 3
[747560.286170] Buffer I/O error on device dm-34, logical block 4
[747560.286687] Buffer I/O error on device dm-34, logical block 5
[747560.287151] Buffer I/O error on device dm-34, logical block 6


Libor

On Čt 12. března 2015 13:20:07 John Stoffel wrote:
> Interesting, so maybe it is working, but from looking at the info
> you've provided, it's hard to know what happened.  I think it might be
> time to do some testing with some loopback devices so you can setup
> four 100m disks, then put them into a VG and then do some LVs on top
> with the RAID5 setup.  Then you can see what happens when you remove a
> disk, either with 'vgreduce' or by stopping the VG and then removing
> a single PV, then re-starting the VG.
> 
> Thinking back on it, I suspect the problem was your vgcfgrestore.  You
> really really really didn't want to do that, because you lied to the
> system.  Instead of four data disks, with good info, you now had three
> good disks, and one blank disk.  But you told LVM that the fourth disk
> was just fine, so it started to use it.    So I bet that when you read
> from an LV, it tried to spread the load out and read from all four
> disks, so you'd get Good, good, nothing, good data, which just totally
> screwed things up.
> 
> Sometimes you were ok I bet because the parity data was on the bad
> disk, but other times it wasn't so those LVs go corrupted because 1/3
> of their data was now garbage.  You never let LVM rebuild the data by
> refreshing the new disk.
> 
> Instead you probably should have done a vgreduce and then vgextend

[-- Attachment #2: Type: text/html, Size: 479133 bytes --]

  reply	other threads:[~2015-03-12 21:32 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-09 11:21 [linux-lvm] Removing disk from raid LVM Libor Klepáč
2015-03-10  9:23 ` emmanuel segura
2015-03-10  9:34   ` Libor Klepáč
2015-03-10 14:05 ` John Stoffel
2015-03-11 13:05   ` Libor Klepáč
2015-03-11 15:57     ` John Stoffel
2015-03-11 18:02       ` Libor Klepáč
2015-03-12 14:53         ` John Stoffel
2015-03-12 15:21           ` Libor Klepáč
2015-03-12 17:20             ` John Stoffel
2015-03-12 21:32               ` Libor Klepáč [this message]
2015-03-13 16:18                 ` John Stoffel
2015-03-12 15:32           ` Libor Klepáč
2015-03-11 23:12 ` Premchand Gupta

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=7038545.HonGYRpauu@libor-nb \
    --to=libor.klepac@bcom.cz \
    --cc=linux-lvm@redhat.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 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.