archive mirror
 help / color / mirror / Atom feed
From: Ken Bass <>
To: Zdenek Kabelac <>
Cc: LVM general discussion and development <>
Subject: Re: [linux-lvm] Problem with partially activate logical volume
Date: Fri, 05 Aug 2022 07:42:40 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

[-- Attachment #1.1: Type: text/plain, Size: 2414 bytes --]

Zdenek: thanks. That makes more sense. I will try after (re-)cloning. Give it  a day or so. 


On Aug 5, 2022, 7:03 AM, at 7:03 AM, Zdenek Kabelac <> wrote:
>Dne 03. 08. 22 v 23:31 Ken Bass napsal(a):
>> That's pretty much it. Whenever any app attempts to read a block from
>> missing drive, I get the "Buffer I/O error" message. So, even though
>> recovery apps can scan the LV, marking blocks on the last drive as 
>> missing/unknown/etc., they can't display any recovered data - which I
>> does exist. Looking at raw data from the apps' scans, I can see
>> entries, as well as files. I'm sure the inodes and bitmaps are still
>there for 
>> some of these, I just can't really reverse engineer and follow them
>> But isn't that what the apps are supposed to do?
>As mentioned by my previous email you shall *NOT* fix the partially
>device in-place - this will not lead to good result.
>User should copy the content to some valid storage device with the same
>as he tries to recover.
>You can 'partially' activate device with  "zero"  filler instead of
>(see the  lvm.conf setting:     missing_stripe_filler="...") - this way
>will just 'read' zero for missing parts.
>Your another 2nd. option is to 'correct' the VG by filling  missing PV
>with a 
>new one with preferable zeroed content - so you will not read 'random'
>in places this new PV will fill the space after your missing PV.
>Although even in this case - I'd still run  'fsck' on the snapshot
>created on 
>top of such LV to give you another chance of recovery if you will pick
>a wrong 
>answer  (since fsck might be 'quite' interactive when doing such
>> Sorry I haven't replied sooner, but it takes a long time (days) to
>clone, then 
>> scan 16Tb...
>> So, please any suggestions are greatly appreciated, as well as
>> ken
>> (I know: No backup; got burned; it hurts; and I will now always have
>> 'Nuf said.)
>Before you run your 'fsck' create a snapshot of your newly created
>and make all the repair actions in the snapshots.
>Once you are 'satisfied' with 'repaired'  filesystem you can then
>snapshot back to your origin and use it.

[-- Attachment #1.2: Type: text/html, Size: 3035 bytes --]

[-- Attachment #2: Type: text/plain, Size: 202 bytes --]

linux-lvm mailing list
read the LVM HOW-TO at

  reply	other threads:[~2022-08-08  7:30 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-25 14:48 [linux-lvm] Problem with partially activate logical volume Ken Bass
2022-07-26  8:50 ` Roger James
2022-07-27 10:49   ` Roger Heflin
2022-07-27 11:26     ` Roger James
2022-08-03 21:31       ` Ken Bass
2022-08-04 11:07         ` Roger Heflin
2022-08-05 12:03         ` Zdenek Kabelac
2022-08-05 12:42           ` Ken Bass [this message]
2022-07-27 19:56 ` Zdenek Kabelac

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:

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

  git send-email \ \ \ \ \

* 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).