[linux-lvm] Another strange setup by a newbie, but strange oops resulted while trying vgextend/vgmerge!

[linux-lvm] Another strange setup by a newbie, but strange oops resulted while trying vgextend/vgmerge!

[Daniel Mitzlaff]

Hello there..
Joe Thornber wrote something like:

>Grab the latest code from the LVM_0-9-patches branch of cvs.  You will
>need to repatch/build the kernel module as well as the userland tools.
Hmm, sorry but – as i sayd in my last mail – CVS snapshots for a machine 
which is imho _very mission critical_
is the last thing that i can add to the "i have no backups" line .. ;)
If i had to wait for the next release of lvm, it's ok. If i had to use an 
old version of LVM, ok ......
But – please can someone add this to the INSTALL file? ;)
>The lvm-2.2.17 and 2.2.18 patches apply cleanly to the vanilla
>kernel + rawio.  The redhat kernel is almost certainly not a vanilla
>kernel.
(smile) i wrote
----
I use a native RH6.2 installation w/o any updates/fixes (except for 
network security), using 2.2.17 and 2.2.18 
kernel-tarballs
----
There's a little difference between "tarballs" (mostly downloaded from 
ftp.kernel.org) and RPM's which came in most cases from redhat or rpmfind 
and are "adapted" versions to run easilyon RH boxes. I took the vanilla 
tarballs from kernel.org;)
And, i can't find any 2.2.18 patches on the ftp servers (again, cvs is no 
choice;)
ok .... but:
>I don't think 0.9 is quite ready for production systems.  Maybe you
>should play with 0.8.
Yessa, that's what i want to hear – why it is not documented in the 
install or readme file?
How can users, which thinks after reading your doc's, that all seems to 
be ok, bug-less and right stable, how can these user see which version is 
stable?;)
I'm such a user, but (remember) i know what i do, and i'm wondering about 
these (initially) cool piece of software;(
Hhhm, i think i'll try a little bit around with 0.8, giving cvs a try 
(but not for real usage!), and really hope that the administrative 
persons learn to declare stable and unstable versions. (smile)
Other question, what is the reason to swap on lvm? ;) Because, as in 
swapon manual described, the kernel already can swap on several devices 
and can handle paralel-swapping on more than one partition .. ;)

Greetings hackbyte -> hackbyte@gmx.de IRCNet hackbyte @ #linux.de,+linux.de
P.s.: Sorry, i just use actually Staroffice on windows for my mails, it's 
not really good (smile) - i'll fix it soon;)

[linux-lvm] Another strange setup by a newbie, but strange oops resulted while trying vgextend/vgmerge!

[Daniel Mitzlaff]

Hello there, first, i'm new to LVM but i understand the concepts – it's 
nice;)
2nd thing, YES i REALLY know what i do – even if it seems that i don't.. 
;)

Ok, just my setup: A Clear RH6.2 w/ kernel 2.2.14 "-5.0" from the rh cd, 
running on a 266K6 w/ DFI Board (wintel TX chipset) + a Adaptec AHA2940AU 
(AIC-7861).
DDRS39130W	9,1G/SDA
DDRS34560W	4,3G/SDB
DTLA307015		15G/HDA
DJNA352030		20G/HDB
DTLA307045		45G/HDD
DTTA351010		10G/HDC
I think, it's cool to use the SCSI drives to boot from plain ext2 
partitions (for some security and recovery reasons), and let the kernel 
handle 2 swap partitions with the same priority (which will let the 
kernel interleave and stripe the swap space itself – whoa, boosting swap 
performace;).
Ok, then i want to build a big vg over all drives. Create a LV with 2 
stripes (hoping that it will everytime use 2 different busses;) and a 
small LV using the left free extends on the VG.

First, i ran into the same problems as reported before here on the list, 
vgmerge and vgextend give me OOPS while extending the LE counter for the 
VG.
BUT, all my drives are filled up with data, there's NO BACKUP(!), and no 
way to take more than a single drive free for reformatting.
So, i tried the patches sent by Heinz – not really knowing where to patch 
it – in the lvm-userland, recompiled – no change at all. Please, tell me 
if it is correct to use the patch at the userland-tools instead of 
patching the kernel-parts. And, can you tell me (and others) in which 
order we have to see the patch?, plain patch for native LVM0.9, are there 
other patches? (CVS snapshots are no choice!)
Ok, next ->
What the heck are you guy's doing? I use a native RH6.2 installation w/o 
any updates/fixes (except for network security), using 2.2.17 and 2.2.18 
kernel-tarballs (the ..17 patches works well on ..18, only a few rejects 
which can easily inserted by hand;). But you CAN'T release a version that 
does not work w/o telling users if they had to look at some dependencies! 
(if there are some, remember i use a really clear RH6.2!)

Ok, so please tell me where i can get a release that works on my server, 
it isn't uncool to me if i had to use an old but STABLE version – but 
tell the users in all your released files WHICH version IS definitively 
STABLE.
Yes, as you can see, i read the complete ML about this problem, i found 
reports and patches adressing this, but there's no help. And don't think 
all your users, who want to use LVM, are able to use CVS snapshots (i 
never use cvs snapshots on my server – release is release – features 
against bugs;).
Grmpf, ok all my frustration is left out, what can we do? ;)
greetings, hackbyte -> hackbyte@gmx.de, IRCNet hackbyte @ #linux.de, 
+linux.de

Re: [linux-lvm] Another strange setup by a newbie, but strange oops resulted while trying vgextend/vgmerge!

[Joe Thornber]

> First, i ran into the same problems as reported before here on the list, 
> vgmerge and vgextend give me OOPS while extending the LE counter for the 
> VG.

Grab the latest code from the LVM_0-9-patches branch of cvs.  You will
need to repatch/build the kernel module as well as the userland tools.

> other patches? (CVS snapshots are no choice!)
Then wait for the next release which shouldn't be too long.

> Ok, next ->
> What the heck are you guy's doing? I use a native RH6.2 installation w/o 
> any updates/fixes (except for network security), using 2.2.17 and 2.2.18 
> kernel-tarballs (the ..17 patches works well on ..18, only a few rejects 
> which can easily inserted by hand;). But you CAN'T release a version that 
> does not work w/o telling users if they had to look at some dependencies! 
> (if there are some, remember i use a really clear RH6.2!)

???  
The lvm-2.2.17 and 2.2.18 patches apply cleanly to the vanilla
kernel + rawio.  The redhat kernel is almost certainly not a vanilla
kernel.

> reports and patches adressing this, but there's no help. And don't think 
> all your users, who want to use LVM, are able to use CVS snapshots (i 
> never use cvs snapshots on my server � release is release � features 
> against bugs;).

I don't think 0.9 is quite ready for production systems.  Maybe you
should play with 0.8.

- Joe

Re: [linux-lvm] Another strange setup by a newbie, but strange oops resulted while trying vgextend/vgmerge!

[lewis]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 5688 bytes --]

On Wed, Jan 03, 2001 at 01:13:14PM +0000, Daniel Mitzlaff wrote:
> First, i ran into the same problems as reported before here on the list, 
> vgmerge and vgextend give me OOPS while extending the LE counter for the 
> VG.

Joe has responded about this already.

> BUT, all my drives are filled up with data, there's NO BACKUP(!), and no 
> way to take more than a single drive free for reformatting.

If this is a production system, you should really should have some backup.
There are plenty of things that can go wrong without even putting layers like
LVM into the picture.  I agree that upgrading LVM should not mess up you're
data, but if you have no backup, you are taking a lot of risks no
matter what. I do understand that for home systems backup is a difficult issue,
but bad things do happen even with the most finely tuned systems.  CD burners
are a cheap and effective way to backup user data, and hard drives are cheap
enough now that you could buy a cheap external drive with large capacity to do
backups to.  That said, it is very unlikely that you will loose data to LVM.
Even the issues that have come up on the list don't cause data corruption.

> So, i tried the patches sent by Heinz – not really knowing where to patch 
> it – in the lvm-userland, recompiled – no change at all. Please, tell me 
> if it is correct to use the patch at the userland-tools instead of 
> patching the kernel-parts. And, can you tell me (and others) in which 
> order we have to see the patch?, plain patch for native LVM0.9, are there 
> other patches? (CVS snapshots are no choice!)

Which patches are you talking about here?

> Ok, next ->
> What the heck are you guy's doing? I use a native RH6.2 installation w/o 
> any updates/fixes (except for network security), using 2.2.17 and 2.2.18 
> kernel-tarballs (the ..17 patches works well on ..18, only a few rejects 
> which can easily inserted by hand;). But you CAN'T release a version that 
> does not work w/o telling users if they had to look at some dependencies! 
> (if there are some, remember i use a really clear RH6.2!)

First of all, if you are using the stock redhat packages, and they don't work
with the new LVM stuff, please complain to RedHat.  They are the ones that
should deal with that. 

Secondly, what are you talking about? --> "version that does not work" 
What is this?  Are you using the RPMs off the sistina site?  Did you compile
the packages yourself?  If you used the sistina packages, make sure the liblvm*
files are removed from /lib.  My initial packages installed into /usr/ instead
of root.  I will get new packages out shortly that correct this problem.  I
was hoping the transition issue would be resolved before I did this, but it
looks like I need to get new packages out first and then deal with that.
You can also look at
http://distro.conectiva.com.br/experimental/lvm/
for a version of the LVM packages that supports both the old (0.8.x) and the
new (0.9.x) interfaces.

> Ok, so please tell me where i can get a release that works on my server, 
> it isn't uncool to me if i had to use an old but STABLE version – but 
> tell the users in all your released files WHICH version IS definitively 
> STABLE.

Define stable.  I don't know of any software package that is 100% stable.
There are always issues to track down.  Point releases, such as LVM 0.9 are
especially prone to that.  You should know that.  If you are concerned about
it, don't upgrade immediately.  Monitor the linux-lvm and lvm-devel mailing
lists and see what problems people have.  That's why we archive the mailing
lists.

> Yes, as you can see, i read the complete ML about this problem, i found 
> reports and patches adressing this, but there's no help. And don't think 
> all your users, who want to use LVM, are able to use CVS snapshots (i 
> never use cvs snapshots on my server – release is release – features 
> against bugs;).

Good, I'm glad you are reading the ML.  We are working on the issues.  Heinz
has been out of contact for a few weeks due to a move and other issues, which
is delaying feedback.  Sorry about that.  :(

> Grmpf, ok all my frustration is left out, what can we do? ;)
> greetings, hackbyte -> hackbyte@gmx.de, IRCNet hackbyte @ #linux.de, 
> +linux.de

I understand your frustration, but know that we are working on this.  As I
said earlier, most point releases have issues that need to be worked out,
and LVM 0.9 is no exception.  If you want a "stable" release, you
should probably use LVM 0.8.1 for now.  LVM 0.9.1 should be out soon, which
should have all the *known* bugs fixed.

Regards,
-- 
AJ Lewis
Sistina Software Inc.                  Voice:  612-379-3951
1313 5th St SE, Suite 111              Fax:    612-379-3952
Minneapolis, MN 55414                  E-Mail: lewis@sistina.com
http://www.sistina.com

Current GPG fingerprint = 3B5F 6011 5216 76A5 2F6B  52A0 941E 1261 0029 2648
Get my key at: http://www.sistina.com/~lewis/gpgkey
 (Unfortunately, the PKS-type keyservers do not work with multiple sub-keys)
-----Begin Obligatory Humorous Quote----------------------------------------
THE LESSER-KNOWN PROGRAMMING LANGUAGES #16:
C- This language was named for the grade received by its creator when he
submitted it as a class project in a graduate programming class.  C- is
best described as a "low-level" programming language.  In fact, the
language generally requires more C- statements than machine-code statements
to execute a given task.  In this respect, it is very similar to COBOL.
-----End Obligatory Humorous Quote------------------------------------------

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

Re: [linux-lvm] Another strange setup by a newbie, but strange oops resulted while trying vgextend/vgmerge!

[Michael J. Declerck]

A short parable seems to be in order here.


  There once was a large penguin rookery located on an island that was
  designated as K-2.2.18.  The penguin population that lived there was large
  and plentiful due to the fact that it provided suitable protection and
  sustenance.  Due to this the population had grown large and was starting
  to look for new territory to occupy.  Lo and behold they discovered
  a substantially larger island known as K-2.4.0 which had a wealth of
  untapped resources that would allow the colony to expand in the future.
  Unfortunately, the distance between K-2.2.18 and K-2.4.0 was large and
  full of many unknown dangers (not the least of which were large killer
  whales looking for tasty penguins to snack on).  

  Despite this, many of the penguin population decided that the risk and
  effort necessary to reach K-2.4.0 was acceptable because of the
  opportunities it provided.  This divided the penguins into a number of
  groups:

  o Group #1 was composed of some of the elder penguins, who had made
  successful ocean crossings in the past.  They traveled together in a flock 
so
  as to mitigate their danger.  They arrived successfully with only minor
  injuries.

  o Group #2 was formed from mature and adolescent penguins.  When they
  ventured forth they either swam in groups for protection or as individuals
  who counted on their own strengths (speed and cunning) to insure a
  successful journey.  Despite this they still encountered dangerous schools
  of jellyfish that inflicted damage upon some of them.  These penguins
  required some time to recuperate after completing their journey

  Group #3 was made up of fledging penguins, who having seen others make the 
  journey, decided they could do so as well.  They launched from shore with
  a plan that consisted of nothing more than a dream of Island K-2.4.0 for
  they were unexperienced in such endeavors.  Many of them became lost
  during the journey or were eaten by killer whales hunting for the
  inexperienced.  Of the remaining penguins, the majority turned back to
  K-2.2.18.  A few of the original group did make it K-2.4.0 and spent much
  time recuperating from the exhausting swim and the mental trauma from having
  seen their friends eaten.

  Group #4 was all the other penguins left on K-2.2.18.  These penguins waited
  a number of months till the ocean calmed down and the killer whales migrated
  to warmer waters.  A this point the majority of them departed from K-2.2.18
  for K-2.4.0 with friendly schools of dolphins to guide them (designated
  Pod-RedHat, Pod-SuSe, Pod-Sistina, etc...).  They arrived without incident
  on K-2.4.0.  Those left on K-2.2.18 maintained the rookery and lived happy
  ever after.

The moral of the story -- If you are a Group #3 penguin don't expect
                          much sympathy from your wiser or more cautious
                          brethren when you get eaten.


---
Michael Declerck, declerck@sistina.com   +1.510.823.7991

Re: [linux-lvm] Another strange setup by a newbie, but strange oops resulted while trying vgextend/vgmerge!

[Daniel Mitzlaff]

Answered to Michael "J." Declerck

> A short parable seems to be in order here.

[skipped a very nice story here... ;)]

> The moral of the story -- If you are a Group #3 penguin don't expect
>                           much sympathy from your wiser or more cautious
>                           brethren when you get eaten.

*smile* .... ok ...
But, what about Penguins which have its own disability's and can't
do such a long jorney to reach K-2.4.0 islands?
Are they all so outdated, that peoples from K-2.4.0
doesn't have to look for them or in any other way care
about them?

You don't remember your own basics?;)

> ---
> Michael Declerck, declerck@sistina.com   +1.510.823.7991

Greetings from good old 2.2.18 islands,
we are still alive (and will probably not die for the next few years;)

hackbyte
P.s.: YOU DON'T REMEMBER YOUR PARENTS? GO INTO YOUR ROOM,
YOU GOT ARREST FOR 2 WEEKS!

Re: [linux-lvm] Another strange setup by a newbie, but strange oops resulted while trying vgextend/vgmerge!

[Michael J. Declerck]

hackbyte@gmx.de said:
> *smile* .... ok ... But, what about Penguins which have its own
> disability's and can't do such a long jorney to reach K-2.4.0 islands?
> Are they all so outdated, that peoples from K-2.4.0 doesn't have to
> look for them or in any other way care about them?

> You don't remember your own basics?;)

I believe that what I said is that those penguins should wait for 
guidance and help from the dolphin pods when the waters were safe.
I didn't say anything about leaving them behind if they wanted to
make the journey then.

As stated in an earlier post Sistina never said the "crossing conditions
with regards to LVM and K-2.4.0 were safe".  These are still uncharted
waters that we are working quickly to make safe.

---
Michael Declerck, declerck@sistina.com   +1.510.823.7991

Re: [linux-lvm] Another strange setup by a newbie, but strange oops resulted while trying vgextend/vgmerge!

[Daniel Mitzlaff]

From  Michael Declerck comes:

> I believe that what I said is that those penguins should wait for
> guidance and help from the dolphin pods when the waters were safe.
> I didn't say anything about leaving them behind if they wanted to
> make the journey then.

Ah, i see. Ok i missunderstand you last mail a little... sorry;)

> As stated in an earlier post Sistina never said the "crossing conditions
> with regards to LVM and K-2.4.0 were safe".  These are still uncharted
> waters that we are working quickly to make safe.

;), did you really understand what i mean with my mails?

It's nice to me, if i can see how good a software will work.
Even if it's alpha or beta software.

But, i'd like to know this after reading the manuals,

*not* only if i try it myself every time;)

And, dont forget, a layer between hdd and fs is ALWAYS
->mission critical<-. Or has to be tested as if it was. (imho)

So, in the manual, somewhere should be a small but important
message about alpha/beta or full stable status.
(At least, linus or whoever maintains the actual
tarball needs such information to decide if a patch/update
is ok for inclusion in a STABLE kernel!;)

regards.... hackbyte aka hackbyte@gmx.de

P.s.: I think, even if you use the actual version numbers like
0,2,4,6 for stable and 1,3,5,7 for unstable versions,
just let us know, that you do so ;)