From: Eddie Atherton <stunnel@attglobal.net>
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] highmem64G Breaks My LVM
Date: Sat, 27 Jun 2009 14:32:26 -0700 [thread overview]
Message-ID: <4A468FEA.8080702@attglobal.net> (raw)
In-Reply-To: <4A271F59.7090607@attglobal.net>
Eddie Atherton wrote:
> Eddie Atherton wrote:
>> I originally posted this on the LinuxQuestions forum:
>> http://www.linuxquestions.org/questions/slackware-14/highmem64g-kills-lvm-728418/
>>
>>
>> I have a fairly vanilla Slack 12.2 system. I recently upped my
>> memory to 8GB, and so recompiled the kernel, making a single change.
>> HIGNMEM4G was changed to HIGHMEM64G. On re-booting, I could see the
>> extra memory, but, unfortunately, I lost all my LVM volumes.
>>
>> After a few checks, I found that vgscan was failing:
>>
>> root@The-Tardis:~# vgscan --mknodes --verbose
>> Wiping cache of LVM-capable devices
>> Wiping internal VG cache
>> Reading all physical volumes. This may take a while...
>> Finding all volume groups
>> /dev/sda1: Checksum error
>> Finding all logical volumes
>>
>> If I reboot back to the HIGHMEM4G kernel, then all works fine again:
>>
>> root@The-Tardis:~# vgscan --mknodes --verbose
>> Wiping cache of LVM-capable devices
>> Wiping internal VG cache
>> Reading all physical volumes. This may take a while...
>> Finding all volume groups
>> Finding volume group "raid_vg"
>> Found volume group "raid_vg" using metadata type lvm2
>> Finding all logical volumes
>>
>> All the LVM volumes reside on an LSI megaRAID card, detected as
>> /dev/sda, which is dedicated to a single PVM.
>>
>> Any ideas why changing the HIGHMEM kernel option would break LVM.
>>
>> Cheers,
>> Eddie
>
> Upgrading to the latest version of the combined device-mapper and lvm:
> 2.02.47 appears to fix this issue.
>
OK, I have to re-open this one. What I didn't check, after running
2.02.47, was that I could read the files on my logical volumes
correctly. In fact I can't. I get a different md5sum from before I
made any changes, to the 2.02.47 version running on the HIGHMEM64G kernel.
So, the bottom line now, after running a number of tests, all with the
2.02.47 version is this:
Using the HIGHMEM4G kernel, everything works perfectly.
Using the HIGHMEM64G kernel I am unable to use any files on my logical
volumes, because of one of the following 2 issues. I have tried
rebooting a number of times, and sometimes the volumes mount, sometimes
they don't:
Either the logical volumes are mounted correctly, but (nearly) every
file I try and read is corrupted, as checked using md5sum.
Or, I cannot mount the volumes because of a checksum error. Here's the
relevant lines from the vgscan:
...
#device/dev-cache.c:259 /dev/sda: Aliased to /dev/block/8:0 in
device cache (preferred name)
#device/dev-cache.c:247 /dev/sda1: Already in device cache
...
#device/dev-io.c:486 Opened /dev/sda RO
#device/dev-io.c:260 /dev/sda: size is 2930307072 sectors
#device/dev-io.c:387 WARNING: /dev/sda already opened read-only
#device/dev-io.c:562 /dev/sda: Immediate close attempt while
still referenced
#device/dev-io.c:532 Closed /dev/sda
#device/dev-io.c:486 Opened /dev/sda RW O_DIRECT
#device/dev-io.c:134 /dev/sda: block size is 4096 bytes
#filters/filter.c:125 /dev/sda: Skipping: Partition table
signature found
#device/dev-io.c:532 Closed /dev/sda
...
#device/dev-io.c:486 Opened /dev/sda1 RO
#device/dev-io.c:260 /dev/sda1: size is 2930304132 sectors
#device/dev-io.c:532 Closed /dev/sda1
#device/dev-io.c:260 /dev/sda1: size is 2930304132 sectors
#device/dev-io.c:486 Opened /dev/sda1 RW O_DIRECT
#device/dev-io.c:134 /dev/sda1: block size is 2048 bytes
#device/dev-io.c:532 Closed /dev/sda1
#filters/filter-composite.c:31 Using /dev/sda1
#device/dev-io.c:486 Opened /dev/sda1 RW O_DIRECT
#device/dev-io.c:134 /dev/sda1: block size is 2048 bytes
#label/label.c:160 /dev/sda1: lvm2 label detected
#cache/lvmcache.c:985 lvmcache: /dev/sda1: now in VG
#orphans_lvm2 (#orphans_lvm2)
#format_text/format-text.c:314 Incorrect metadata area header checksum
#format_text/format-text.c:1059 <backtrace>
#device/dev-io.c:532 Closed /dev/sda1
...
So, to me, it appears that LVM2 is incompatible with a kernel built with
HIGHMEM64G.
Cheers,
Eddie
prev parent reply other threads:[~2009-06-27 21:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-01 6:39 [linux-lvm] highmem64G Breaks My LVM Eddie Atherton
2009-06-04 1:11 ` Eddie Atherton
2009-06-27 21:32 ` Eddie Atherton [this message]
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=4A468FEA.8080702@attglobal.net \
--to=stunnel@attglobal.net \
--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.