linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
* Re: [linux-lvm] RH 6.2 kernel problem with 0.8i
@ 2000-05-02  9:55 Michael Marxmeier
  0 siblings, 0 replies; 3+ messages in thread
From: Michael Marxmeier @ 2000-05-02  9:55 UTC (permalink / raw)
  To: linux-lvm

Forwarded message ...

-------- Original Message --------
Message-ID: <390E294C.698DDB17@t-online.de>
Date: Tue, 02 May 2000 03:03:08 +0200
From: Heinz.Mauelshagen@t-online.de (Heinz Mauelshagen)
Subject: Re: [linux-lvm] RH 6.2 kernel problem with 0.8i
References: <20000501194313.A25404@omnifarious.mn.org>


"Eric M. Hopper" wrote:

>         I figured out my problem.  It's the RAID patches that RH adds.
>
>         RH adds a LOT of patches to the stock kernel.  Someone suggested
> grabbing a stock kernel and using that, but a lot of the RH patches are
> ones I really want, and I don't want to sift through them carefully
> figuring out which ones.
>
>         So, I grabbed the kernel source RPM, used rpm2cpio on it,
> unpacked the cpio, and then used patch -R (what a wonderful tool) to
> reverse the patches I didn't want out of the kernel source tree RH
> ships.
>
>         After that, the LVM patches applied just fine.  I only wanted
> RAID0 anyway, and LVM does that just fine by itself.  :-)

O.k.

>
>
>         It works beautifully!
>
>         The only thing I could ask for (and it is something that would
> be complicated to dp) is to allow the root filesystem to be a logical
> volume.

Yes, it is partially supported by the lvmcreate_nitrd(8) tool
contained
in the lvm distribution which creates a initial ram disk enabling
volume
group activation and change of the root filesystem from the initial
ram disk
to a logical volume containing a root filesystem.
Nevertheless there's no support to setup the contents of the root
filesystem
in the logical volume an the lilo configuration file.

>
>
>         A graphical (say tk or Python based) manager might be nice to,
> but there are already several people working on that.

>
>         Thanks a LOT for providing such a neat, useful tool.  Virtual
> memory for hard drives.  It's great!
>
>         One question...
>
>         Is the warning about moving the physical extents of a mounted
> logical volume based on hard evidence, or uneasiness?

The reason for this message is, that a power loss or a system damage
can cause a LVM metadata (VGDA) inconsistency which will force the
administrator
to restore the VGDA from a backup copy in /etc/lvmconf/.
Another rason is. that buffers contained in the buffer cache
which are not written to the physical volumes can get lost in this
case as well.


>
>
>         As I recall from Hans's talk, there shouldn't be any problem.  I
> think I remember that the blocks are locked from being read or written
> to while they're being moved.

Yes, they are locked and after the data move and metadata update, they
are unlocked

for further access again.

> And besides, the buffer cache entries
> point at the logical volume anyway.

Correct.

>
>
> Have fun (if at all possible),

You as well ;-{)

Heinz

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [linux-lvm] RH 6.2 kernel problem with 0.8i
       [not found] ` <390E294C.698DDB17@t-online.de>
@ 2000-05-02  2:06   ` Eric M. Hopper
  0 siblings, 0 replies; 3+ messages in thread
From: Eric M. Hopper @ 2000-05-02  2:06 UTC (permalink / raw)
  To: linux-lvm

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

On Tue, May 02, 2000 at 03:03:08AM +0200, Heinz Mauelshagen wrote:
> "Eric M. Hopper" wrote:
> 
>>         I figured out my problem.  It's the RAID patches that RH adds.
>>
>>         RH adds a LOT of patches to the stock kernel.  Someone suggested
>> grabbing a stock kernel and using that, but a lot of the RH patches are
>> ones I really want, and I don't want to sift through them carefully
>> figuring out which ones.
>>
>>         So, I grabbed the kernel source RPM, used rpm2cpio on it,
>> unpacked the cpio, and then used patch -R (what a wonderful tool) to
>> reverse the patches I didn't want out of the kernel source tree RH
>> ships.
>>
>>         After that, the LVM patches applied just fine.  I only wanted
>> RAID0 anyway, and LVM does that just fine by itself.  :-)

	BTW, I should've mentioned the patches I had to back out.  These
are what they were named in the kernel SRPM.

linux-2.2.12-PIII-xor.patch
linux-2.2.14-sparc-raid.patch
raid-2.2.14-B1.gz

	I believe the patches have to be reverse applied in the given
order.

Have fun (if at all possible),
-- 
Its name is Public Opinion.  It is held in reverence. It settles everything.
Some think it is the voice of God.  Loyalty to petrified opinion never yet
broke a chain or freed a human soul.     ---Mark Twain
-- Eric Hopper (hopper@omnifarious.mn.org  http://omnifarious.mn.org/~hopper) --

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [linux-lvm] RH 6.2 kernel problem with 0.8i
@ 2000-05-02  0:43 Eric M. Hopper
       [not found] ` <390E294C.698DDB17@t-online.de>
  0 siblings, 1 reply; 3+ messages in thread
From: Eric M. Hopper @ 2000-05-02  0:43 UTC (permalink / raw)
  To: linux-lvm

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

	I figured out my problem.  It's the RAID patches that RH adds.

	RH adds a LOT of patches to the stock kernel.  Someone suggested
grabbing a stock kernel and using that, but a lot of the RH patches are
ones I really want, and I don't want to sift through them carefully
figuring out which ones.

	So, I grabbed the kernel source RPM, used rpm2cpio on it,
unpacked the cpio, and then used patch -R (what a wonderful tool) to
reverse the patches I didn't want out of the kernel source tree RH
ships.

	After that, the LVM patches applied just fine.  I only wanted
RAID0 anyway, and LVM does that just fine by itself.  :-)

	It works beautifully!

	The only thing I could ask for (and it is something that would
be complicated to dp) is to allow the root filesystem to be a logical
volume.

	A graphical (say tk or Python based) manager might be nice to,
but there are already several people working on that.

	Thanks a LOT for providing such a neat, useful tool.  Virtual
memory for hard drives.  It's great!

	One question...

	Is the warning about moving the physical extents of a mounted
logical volume based on hard evidence, or uneasiness?

	As I recall from Hans's talk, there shouldn't be any problem.  I
think I remember that the blocks are locked from being read or written
to while they're being moved.  And besides, the buffer cache entries
point at the logical volume anyway.

Have fun (if at all possible),
-- 
Its name is Public Opinion.  It is held in reverence. It settles everything.
Some think it is the voice of God.  Loyalty to petrified opinion never yet
broke a chain or freed a human soul.     ---Mark Twain
-- Eric Hopper (hopper@omnifarious.mn.org  http://omnifarious.mn.org/~hopper) --

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2000-05-02  9:55 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-05-02  9:55 [linux-lvm] RH 6.2 kernel problem with 0.8i Michael Marxmeier
  -- strict thread matches above, loose matches on Subject: below --
2000-05-02  0:43 Eric M. Hopper
     [not found] ` <390E294C.698DDB17@t-online.de>
2000-05-02  2:06   ` Eric M. Hopper

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