[linux-lvm] lvm question regarding start and placement of data

[linux-lvm] lvm question regarding start and placement of data

[L A Walsh]

I have a file in the /etc/lvm/archive dir that seems to be the name of a vg.


I see:
Data {
    seqno = 1933
    format = "lvm2" # informational
    status = ["RESIZEABLE", "READ", "WRITE"]
    extent_size = 8192        # 4 Megabytes
    max_lv = 0
    max_pv = 0
    metadata_copies = 0

    physical_volumes {
        pv0 {
            device = "/dev/sdb1"    # Hint only
            status = ["ALLOCATABLE"]
            flags = []
            dev_size = 93755273216    # 43.6582 Terabytes
            pe_start = 2048
            pe_count = 11444735    # 43.6582 Terabytes
        }
    }

    logical_volumes {
        Home {
            allocation_policy = "contiguous"
            segment_count = 1
            segment1 {
                start_extent = 0
                extent_count = 393216    # 1.5 Terabytes
                type = "striped"
                stripe_count = 1    # linear
                stripes = [ "pv0", 0 ]
            }
        }
----
It appears that the start of the physical vol is at 2048 but not sure
what the units are --
Are those 2048 physical extents of size 8192 and is said to be
equivalent to 4MB?  So the 8192 is a number of 512 byte sectors
(even though they underlying disk is 4K with 512e)?

At the start of the physical volume at 2048 should I see the logical
volume 'Home' as it starts at extent '0'?

So shouldn't I see the start of the Home partition 8MB in from the
front?  Or is there something else before physical volumns?  Does
first logical volume start at pe_start?

I.e. I'm assuming I have something wrong, because I'm not seeing anything
looking like the beginning of a file system at that location...

Thanks....

Re: [linux-lvm] lvm question regarding start and placement of data

[Alasdair G Kergon]

On Tue, Jul 21, 2020 at 05:23:47PM -0700, L A Walsh wrote:
> I have a file in the /etc/lvm/archive dir that seems to be the name of a vg.
 
Use the tools to explain what you have where:
  pvs, lvs, vgs 
with -o help to see the list of fields available
and --units to select your choice of output units.

(Offset from start of disk and extent size is recorded as 512-byte sectors;
Within VGs units are extents.)

Alasdair

Re: [linux-lvm] lvm question regarding start and placement of data

[L A Walsh]

I don't think the tools work on bare disk (or disk images).  This is a
bit of a background, and earlier note that might explain more what I
am asking and why I am asking and not looking at the output of tools:

---------- Forwarded message ---------
From: L A Walsh <lvm@tlinx.org>
Date: Wed, Jul 8, 2020 at 11:58 AM
Subject: Finding beginning of lvm log and data recovery


I am trying to find the beginning of what looks like some lvm metadata
that seems to be printed into about 6-64K segments (part of a RAID10
that was on an LSI-card-raid that went belly up).  The raid used
64K/disk in what appears to be an 11-disk RAID0 (mirrored) out of 24
disks (I think 2/24 were spares, but this was created about 7 years
ago).

I'm beginning to wonder if this is a circular log since I can't really
find the beginning or end, but I do seem to find 2 copies of items
(no, it's not the RAID pair).

The first part of the one of the disks shows:
-----
 1    # linear

stripes = [
"pv0", 1618634
]
}
}

Home-2015.05.23-04.08.02 {
id = "jCsttc-l9To-SHtI-sqFu-YEbv-nWhp-Wy63A4"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
creation_host = "Ishtar"
creation_time = 1432636568
segment_count = 1

segment1 {
start_extent = 0
extent_count = 1146

type = "striped"
stripe_count = 1    # linear

stripes = [
"pv0", 1619220
]
}
}
------------------------
I found about 5-6 more 64K sections at the same offset
(2nd 64K on the disk numbering from 0) that appear to be contiguous
with each other, but the beginning and end seem to be not there.

I also have the root file system's /etc/lvm (and a copy made over a
month ago) to make sure things didn't get overwritten, with items
like:
Ishtar:/etc> ll /etc/lvm
total 128
-rw-rw-r-- 1  8884 Sep 12  2011 Home+Space.vg
drwxrwxr-x 2 24576 Jun 24 12:02 archive/
drwxrwxr-x 2   110 Jun 24 12:02 backup/
drwxrwx--- 2     6 Apr 24 01:46 cache/
-rw-rw-r-- 1 39253 Feb 26  2016 lvm.conf
-rw-rw-r-- 1 10906 Jul 19  2010 lvm.conf.orig
-rw-rwxr-- 1 10968 Mar 10  2013 lvm.conf.rpmorig*
-rw-rwxr-- 1 10930 Sep 21  2011 lvm.conf.rpmsave*
drwxrwxr-x 2     6 Jan 15  2015 metadata/
-rw-rw-r-- 1  8512 Sep 12  2011 nHome+Space.orig
-----

I've found about 9** pairs of the mirror
(pairs as determined by an md5sum of the first 4GB)
I have 4 unknowns at this point (need to re-md5sum them in
different areas to see if they might be mirrors that have junk at the
beginning?)

I think the entire disk was in lvm (24 disks, 11 data mirrored on
another 11 with 2 spares. (4tdB disks ).
(td=tera-decimal-Bytes)

Yes, I had backups that also got knocked offline the same day --
controller went south, xfs didn't like what was being written and
turned off file systems.  The backups
were incrementals of the "important stuff" on a similar setup (11 data
on RAID10 of 2tdB disks).

Found a 10th pair that has a boot record at the beginning:

 DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,1),
end-CHS (0x3ff,254,63), startsector 1, 4294967295 sectors, extended
partition table (l
ast)

but has some differences between the two pairs in the first 1G
(thinking  one disk of the pair got written and the other did not)?

The last 2 disks I see don't appear to to be dups, one could be a
spare -- also I can't read the disk in slot23, as it has a bad PHY.

While the new controller had the disks come up as sdc-sds in JBOD
mode, I don't know what disk is in what slow.  Going to have to try
saturating them (the identify drive function isn't working with this
container).

So anyway to determine the start of the LVM log on disk?

How about info out of /etc/lvm?  Anything there people can think of
that would help.  I think I am getting close, but my nervousness level
goes up as I get closer for fear that either things won't "fit
together" or I'll forget something and do something foolish.  Even
knowing the right order, its still seems like it will be a pain to
reconstruct 1 copy of the RAID (a RAID0 essentially),
since I need to sweep across the RAID0 set reading 64k of
each "disk" to write contiguously somewhere.

Thanks for any pointers.
Linda W.


On Tue, Jul 21, 2020 at 5:40 PM Alasdair G Kergon <agk@redhat.com> wrote:
>
> On Tue, Jul 21, 2020 at 05:23:47PM -0700, L A Walsh wrote:
> > I have a file in the /etc/lvm/archive dir that seems to be the name of a vg.
>
> Use the tools to explain what you have where:
>   pvs, lvs, vgs
> with -o help to see the list of fields available
> and --units to select your choice of output units.
>
> (Offset from start of disk and extent size is recorded as 512-byte sectors;
> Within VGs units are extents.)
>
> Alasdair
>

Re: [linux-lvm] lvm question regarding start and placement of data

[Alasdair G Kergon]

On Tue, Jul 21, 2020 at 05:47:07PM -0700, L A Walsh wrote:
> I don't think the tools work on bare disk (or disk images).  This is a

There are ways to do it, but download a recent upstream version and read
the pvck man page which now has extra analysis facilities.

> I'm beginning to wonder if this is a circular log since I can't really

Yes - see for example Metadata slides at
  http://people.redhat.com/agk/talks/LVM2-LinuxTag2006/

Alasdair

Re: [linux-lvm] lvm question regarding start and placement of data

[L A Walsh]

On Tue, Jul 21, 7:38PM,  Alasdair G Kergon wrote
>On Tue, Jul 21, 2020 at 05:47:07PM -0700, L A Walsh wrote:
>> I don't think the tools work on bare disk (or disk images).  This is a
>
>There are ways to do it, but download a recent upstream version and read
>the pvck man page which now has extra analysis facilities.

-----
What version is recent, my distro, SuSE Tumbleweed (rolling distro),
recently put out lvm2-2.03.05, but not seeing how pvck would help
in my situation.

Right now, I have 24 disk image files, 10 of which matched another 10, so
I discarded the copies from my working set of images and currently have
14.  Two of those are supposed to be mirrors of the other two, but are
are not, so in addition to finding the order of the 10-known mirrored drives,
I have 4 that don't have matching chksums at the beginning.

I renamed the image files lda-ldn to get my head away from thinking about
the drives' current names.  lda-ldj are disk images that have a known
pair while ld{k,l,m,n} need order and correct copy identification (if there
is one, semi-presuming one is probably a good/valid copy but it's mirror
is corrupt).

Started using the 1st 4G, md5sum'd to identify mirrored pairs -- have that
data off in a hash, so if the drives come up with a different order,
I can re-ID the logical name from the md5sum.  Nxt, I was planning on
looking in other areas on the 4 mystery disks for ones that would match.

I am not seeing how I'd use pvck to find such info at this point.  It
talks about
adding more Metadata copies, but that's good for all-ok drives, and
I don't see that being useful for a 24disk RAID10, broken into
individual iimages (where I've ID'd 10 that did match).

Is there a newer version that would help in this situation?
Thanks!




On Tue, Jul 21, 2020 at 7:38 PM Alasdair G Kergon <agk@redhat.com> wrote:
>
> On Tue, Jul 21, 2020 at 05:47:07PM -0700, L A Walsh wrote:
> > I don't think the tools work on bare disk (or disk images).  This is a
>
> There are ways to do it, but download a recent upstream version and read
> the pvck man page which now has extra analysis facilities.
>
> > I'm beginning to wonder if this is a circular log since I can't really
>
> Yes - see for example Metadata slides at
>   http://people.redhat.com/agk/talks/LVM2-LinuxTag2006/
>
> Alasdair
>