[linux-lvm] LVM2 setup notes and questions

[Nathan G. Grennan]

On Wed, 2002-08-07 at 03:38, Joe Thornber wrote:
> Nathan,
> 
> Thanks for your mail, this sort of information is really helpful.
> 

You are welcome.

> 
> I think maybe we should disable readline support by default, very few
> people use it.
>

Good
 
> 
> I think this is more of a distro problem than an LVM2 prob.
> 

This could be fixed in the LVM2 tools, though is probably also fixable
in the distribution.

> > The next problem I ran into was a common one of vgscan trying to scan
> > cdrom drives at hda and hdc. After reading the man page for lvm.conf and
> > doing a little Google searching I figure out the correct format to
> > filter both. I think the man page could use some additional examples to
> > show the format for more than one filter.
> 
> Did you find the examples in LVM/doc/example.conf ?
>

locate example.conf  shows no LVM example.conf on the system, both in
the installed areas and the build directories.

 
> 
> There should automatically be a symbolic link from /dev/vg/data to
> /dev/device-mapper/vg-data.  Can you confirm that this isn't happening
> on your system please ?
>

No, but as I thought about it though I realized why. I think I had
device files left over from my LVM1 setup and so I have been using a
mixed up device setup. I will work on getting it setup correctly.
 
> Format2 hasn't been released yet, it's currently undergoing a lot of
> testing, we want to be confident it is correct before trusting peoples
> data to it.  The upgrade procedure will be in the form a little shell
> script which backs up your vgs in the normal text format, and then
> restores from this text format to new format2 metadata areas.
>

ok, I asked because I noticed the boot messages mentioned the metadata
was still LVM1.
 
> The partition will count as a PV, so just use vgextend, eg,
> 
> vgextend vg0 /dev/hdc2
> 
> Not sure what you mean here, if you are asking if LVM2 will
> automatically resize filesystems the answer is no.  We're just
> concentrating on volume management, not filesystem management.
>

I later figured this all out, and it was a little more complicated than
that. I also found there is a tool that is meant to expand the logical
volume and filesystem with one command, but it isn't implemented yet.

> I can't think of any major bug that would force you to upgrade.
> 
> We tend to work off an internal bitkeeper repository and occasionally
> sync up with CVS or the public bitkeeper.  So you shouldn't be shy
> about using the CVS version since it is very stable.
> 
> If you are a bitkeeper user the latest stable 2.4 version can be
> pulled from:
> 
> bk://device-mapper.bkbits.net/2.4-stable
> 
> This gets updated more frequently than cvs.  You can see the changeset log here:
> 
> http://device-mapper.bkbits.net:8080/2.4-stable
> 

ok, I will look into that and likely switch to a more recent version.

 
> /dev/device-mapper is being renamed to /dev/mapper (kernel hackers
> don't like typing).  So if you do pick up patches that implement this
> change (ie. from bitkeeper), please remember to rebuild libdevmapper.
> 

ok, good to hear it is being simplified even more.