From: Gregory Ade <gkade@bigbrother.net>
To: linux-lvm@sistina.com
Subject: Re: [linux-lvm] strange behavior with 1.0.5 on Linux 2.4.19?
Date: Thu Nov 7 21:45:01 2002 [thread overview]
Message-ID: <1036727077.7035.50.camel@pslgregory> (raw)
In-Reply-To: <20021105152824.E27825@sistina.com>
[-- Attachment #1: Type: text/plain, Size: 2212 bytes --]
On Tue, 2002-11-05 at 06:28, Heinz J . Mauelshagen wrote:
> > > If you have a chance to reconfigure the failing system temporarily,
> > > running what you did before should reproduce the same problems (segfault
> > > on snapshot creation after fresh reboot) in case there's _no_ bug in the
> > > large/high memory support.
> > > My assumption is that it will not.
> There's no need to physically remove any DIMMs. Just cook up a kernel
> without the patches you mentioned to get that elefant going and
> without high memory support.
Okay, I disabled high memory support (only change from production
kernel), rebooted with this test kernel, and tried to create a snapshot:
root@burpr(pts/0):~ 26 # lvcreate --snapshot --extents 512 --name
tmp_snap /dev/vg00/tmp
lvcreate -- INFO: using default snapshot chunk size of 64 KB for
"/dev/vg00/tmp_snap"
lvcreate -- doing automatic backup of "vg00"
lvcreate -- logical volume "/dev/vg00/tmp_snap" successfully created
It worked just fine:
root@burpr(pts/1):log 28 # lvdisplay /dev/vg00/tmp
--- Logical volume ---
LV Name /dev/vg00/tmp
VG Name vg00
LV Write Access read/write
LV snapshot status source of
/dev/vg00/tmp_snap [active]
LV Status available
LV # 2
# open 1
LV Size 2 GB
Current LE 512
Allocated LE 512
Allocation next free
Read ahead sectors 120
Block device 58:1
So I removed it:
root@burpr(pts/1):log 29 # lvremove /dev/vg00/tmp_snap
lvremove -- do you really want to remove "/dev/vg00/tmp_snap"? [y/n]: y
lvremove -- doing automatic backup of volume group "vg00"
lvremove -- logical volume "/dev/vg00/tmp_snap" successfully removed
No kernel oops or BUG in the dmesg.
Again, the _ONLY DIFFERENCE_ between this test kernel and the production
kernel is the high-memory support option. On the test kernel, it is
off, and on the production kernel, it is set to 64GB.
Hope this helps.
--
Gregory K. Ade <gkade@bigbrother.net>
http://bigbrother.net/~gkade
OpenPGP Key ID: EAF4844B keyserver: pgpkeys.mit.edu
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]
next prev parent reply other threads:[~2002-11-07 21:45 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-02 12:23 [linux-lvm] strange behavior with 1.0.5 on Linux 2.4.19? Gregory K. Ade
2002-10-04 3:54 ` Heinz J . Mauelshagen
2002-10-08 15:07 ` Gregory Ade
2002-10-09 6:38 ` Heinz J . Mauelshagen
2002-10-27 22:30 ` Gregory K. Ade
2002-10-28 3:21 ` Heinz J . Mauelshagen
2002-10-28 22:38 ` Gregory K. Ade
2002-10-29 3:15 ` Heinz J . Mauelshagen
2002-10-29 13:54 ` Gregory K. Ade
2002-10-31 6:52 ` Heinz J . Mauelshagen
2002-10-31 16:55 ` Gregory Ade
2002-11-01 9:07 ` Wolfgang Weisselberg
2002-11-05 8:33 ` Heinz J . Mauelshagen
2002-11-07 21:45 ` Gregory Ade [this message]
2002-11-09 6:12 ` Heinz J . Mauelshagen
2002-11-11 5:56 ` Jon Bendtsen
2002-11-22 15:51 ` Gregory Ade
2002-12-05 21:35 ` Gregory Ade
2002-10-28 14:36 ` jon+lvm
2002-10-28 16:40 ` Gregory K. Ade
2002-10-29 15:21 ` Luca Berra
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=1036727077.7035.50.camel@pslgregory \
--to=gkade@bigbrother.net \
--cc=linux-lvm@sistina.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.