[linux-lvm] Revised petition WAS: LVM in stock kernel!?

[linux-lvm] Revised petition WAS: LVM in stock kernel!?

[Andreas Dilger]

Shane writes:
> - Integration with IBM's ADSM backup allows Linux machines to be backed up
>   "snapshot" style by simply syncing volumes and grabbing volume data.

I would like to learn specifically what this is before we post this list
anywhere.  I don't know of any "integration" with ADSM and Linux LVM.  I
don't think the current LVM supports mirrored LVs, so there is no possibility
of a snapshot of a filesystem...

> - The ability to add a sort of volume log allows almost instant volume
>   resyncing while maintaining an active data volume.

I don't think this is currently possible either with Linux LVM...  Let's
stick with what works before we go talking about features that don't
exist yet.

You can add me as a strong supporter of LVM for Linux.  I think any OS
that doesn't have LVM these days is a pain in the a**.

Cheers, Andreas
-- 
Andreas Dilger  University of Calgary \ "If a man ate a pound of pasta and
                Micronet Research Group \ a pound of antipasto, would they
Dept of Electrical & Computer Engineering \  cancel out, leaving him still
http://www-mddsp.enel.ucalgary.ca/People/adilger/      hungry?" -- Dogbert

Re: [linux-lvm] Revised petition WAS: LVM in stock kernel!?

[Luca Berra]

I completely agree with Andreas, snapshots and volume logs
are a feature of veritas vxfs (journaled filesystem)
not veritas LVM. 
On Thu, Aug 26, 1999 at 09:38:37PM -0600, Andreas Dilger wrote:
> Shane writes:
> > - Integration with IBM's ADSM backup allows Linux machines to be backed up
> >   "snapshot" style by simply syncing volumes and grabbing volume data.
> 
> I would like to learn specifically what this is before we post this list
> anywhere.  I don't know of any "integration" with ADSM and Linux LVM.  I
> don't think the current LVM supports mirrored LVs, so there is no possibility
> of a snapshot of a filesystem...
> 
> > - The ability to add a sort of volume log allows almost instant volume
> >   resyncing while maintaining an active data volume.
> 
> I don't think this is currently possible either with Linux LVM...  Let's
> stick with what works before we go talking about features that don't
> exist yet.
> 
> You can add me as a strong supporter of LVM for Linux.  I think any OS
> that doesn't have LVM these days is a pain in the a**.
> 
> Cheers, Andreas
> -- 
> Andreas Dilger  University of Calgary \ "If a man ate a pound of pasta and
>                 Micronet Research Group \ a pound of antipasto, would they
> Dept of Electrical & Computer Engineering \  cancel out, leaving him still
> http://www-mddsp.enel.ucalgary.ca/People/adilger/      hungry?" -- Dogbert
> 

-- 
Luca Berra -- bluca@comedia.it
    Communications Media & Services S.r.l.

Re: [linux-lvm] Revised petition WAS: LVM in stock kernel!?

[Heinz Mauelshagen]

> 
> I completely agree with Andreas, snapshots and volume logs
> are a feature of veritas vxfs (journaled filesystem)
> not veritas LVM. 
> On Thu, Aug 26, 1999 at 09:38:37PM -0600, Andreas Dilger wrote:
> > Shane writes:
> > > - Integration with IBM's ADSM backup allows Linux machines to be backed up
> > >   "snapshot" style by simply syncing volumes and grabbing volume data.
> > 
> > I would like to learn specifically what this is before we post this list
> > anywhere.  I don't know of any "integration" with ADSM and Linux LVM.  I
> > don't think the current LVM supports mirrored LVs, so there is no possibility
> > of a snapshot of a filesystem...
> > 
> > > - The ability to add a sort of volume log allows almost instant volume
> > >   resyncing while maintaining an active data volume.

Yep.

> > 
> > I don't think this is currently possible either with Linux LVM...

Yes, you are right as far as LVM 0.7 is concerned.

> > Let's
> > stick with what works before we go talking about features that don't
> > exist yet.

I'm working on LV snapshot support right now.

I'ld like to have it in 0.8 because it would be a block device level
feature, which can be used by each and every block device
user (FSes/DBMSes/...).

IMO this conforms to the 'better do things generic' approach.

<SNIP>

Regards,
Heinz
--

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Systemmanagement CS-TS                           T-Nova
                                                 Entwicklungszentrum Darmstadt
Heinz Mauelshagen                                Otto-Roehm-Strasse 71c
Senior Systems Engineer                          Postfach 10 05 41
                                                 64205 Darmstadt
mge@ez-darmstadt.telekom.de                      Germany
                                                 +49 6151 886-425
                                                          FAX-386
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-lvm] Revised petition WAS: LVM in stock kernel!?

[Steve Brueggeman]

Since we're petitioning Linus to include 'current' LVM code, I believe that we
should make it clear what Linux LVM 'currently' supports.  Though a section
including future growth would probably be a good idea, since it'd give Linus a
good feeling about future support, and also let him know what direction this
piece of code is going in. 

Of course, include my name on the petition.

steve_brueggeman@notes.seagate.com

Steve Brueggeman


>Shane writes:
>> - Integration with IBM's ADSM backup allows Linux machines to be backed up
>>   "snapshot" style by simply syncing volumes and grabbing volume data.
>
>I would like to learn specifically what this is before we post this list
>anywhere.  I don't know of any "integration" with ADSM and Linux LVM.  I
>don't think the current LVM supports mirrored LVs, so there is no possibility
>of a snapshot of a filesystem...
>
>> - The ability to add a sort of volume log allows almost instant volume
>>   resyncing while maintaining an active data volume.
>
>I don't think this is currently possible either with Linux LVM...  Let's
>stick with what works before we go talking about features that don't
>exist yet.
>
>You can add me as a strong supporter of LVM for Linux.  I think any OS
>that doesn't have LVM these days is a pain in the a**.
>
>Cheers, Andreas

Re: [linux-lvm] Revised petition WAS: LVM in stock kernel!?

[S. Ryan Quick]

-----BEGIN PGP SIGNED MESSAGE-----

On Thu, 26 Aug 1999, Andreas Dilger wrote:

> Shane writes:
> > - Integration with IBM's ADSM backup allows Linux machines to be backed up
> >   "snapshot" style by simply syncing volumes and grabbing volume data.
> 
> I would like to learn specifically what this is before we post this list
> anywhere.  I don't know of any "integration" with ADSM and Linux LVM.  I
> don't think the current LVM supports mirrored LVs, so there is no possibility
> of a snapshot of a filesystem...

I've been able to succesully mirror lvs using the raid0 implmentation along with LVM since I started using it.
As for the snapshot backup, in a nutshell, you simply mark a stale mirror (or break the mirror temporarily),
and set ADSM to back up the logical volume directly (works fine, and quickly)  Again, I've been using the Linux
adsm client for almost 2 years now (pays to be an insider with IBM hehehe), and once LVM came out I immediately
began testing LV backups.  True, a data restore requires a complete rebuild of the mirror, but the client will
get it.  In some situations this is not optimal (e.g. if you have a filesystem using the LV), but in the case
of raw LV access (e.g. Sybase/Oracle/DB2), it works well.

> 
> > - The ability to add a sort of volume log allows almost instant volume
> >   resyncing while maintaining an active data volume.
> 
> I don't think this is currently possible either with Linux LVM...  Let's
> stick with what works before we go talking about features that don't
> exist yet.


This is not yet, but I'm working on it ;-)

> 
> You can add me as a strong supporter of LVM for Linux.  I think any OS
> that doesn't have LVM these days is a pain in the a**.

Ditto.  Glad to see my name high up on the list.


> 
> Cheers, Andreas
> -- 
> Andreas Dilger  University of Calgary \ "If a man ate a pound of pasta and
>                 Micronet Research Group \ a pound of antipasto, would they
> Dept of Electrical & Computer Engineering \  cancel out, leaving him still
> http://www-mddsp.enel.ucalgary.ca/People/adilger/      hungry?" -- Dogbert
> 

%                                                       %%%%%%%%%%
%%           S. Ryan Quick                               %%%%%%%%%
%%%           UNIX Systems Engineer                       %%%%%%%%
%%%%           Phaedo Consulting, Inc. -- Exec VP          %%%%%%%
%%%%%                                                       %%%%%%
%%%%%%         www.phaedo.com/ryan/  ryan@phaedo.com         %%%%%
%%%%%%%       ------------ PGP FingerPrint -------------      %%%%
%%%%%%%%  CF 19 6B BA 31 8E B8 8E  20 DF 4F 2B 2E 69 81 F5     %%%
%%%%%%%%%     ------------------------------------------        %%
%%%%%%%%%%                                                       %

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv

iQCVAwUBN8awrvUYDAQiV+tNAQEl5QP/WUQ+eVnMvso5k2gX3sl1+w74W9frkJq5
Zif1KaRd49O+f3WSh/rBLX4wUdK0fk7p5Z4lSjFj45HdrgHPRFqTdhksCAQ+eV2O
s02/XcfzWgyM3gnckR8JNvFV9lsNQ+ZZOK0bv6e+crpT+aZaufZRa5caiQXAzEVp
rArNfC62Ceg=
=wK8R
-----END PGP SIGNATURE-----

Re: [linux-lvm] Revised petition WAS: LVM in stock kernel!?

[Mats Wichmann]

>
>I've been able to succesully mirror lvs using the raid0 implmentation 
>along with LVM since I started using it.
>As for the snapshot backup, in a nutshell, you simply mark a stale mirror 
>(or break the mirror temporarily),
>and set ADSM to back up the logical volume directly (works fine, and 
>quickly)  Again, I've been using the Linux
>adsm client for almost 2 years now (pays to be an insider with IBM 
>hehehe), and once LVM came out I immediately
>began testing LV backups.  True, a data restore requires a complete 
>rebuild of the mirror, but the client will
>get it.  In some situations this is not optimal (e.g. if you have a 
>filesystem using the LV), but in the case
>of raw LV access (e.g. Sybase/Oracle/DB2), it works well.

This is not quite the same concept as snapshot filesystems, although you
can certainly use it for reliable backups (quiescent filesystems!).  With a 
spare
disk you can even use lv and a floating mirror disk to help back up several 
mirrored
devices - attach it to one mirror, sync up, detach and backup, attach to 
another
mirror, sync, etc.

Snapshots (at least the concept that Veritas has described to the world) 
let you
freeze the state of a filesystem as a read-only image while the filesystem 
itself
remains live, but without breaking any mirrors and leaving yourself 
temporarily in
an unmirrored state.  All you really need is to be able to freeze a pointer 
to the
metadata, and set the FS into a state such that no disk block can be modified,
instead it's always copied on write.  Requires suitable filesystem support, of
course.  Those extra blocks are released only when you're done with the 
snapshot.
Snapshots can live for as long as you want, and there can be several of them
active, as long as you have disk space that is.

Re: [linux-lvm] Revised petition WAS: LVM in stock kernel!?

[S. Ryan Quick]

-----BEGIN PGP SIGNED MESSAGE-----

On Fri, 27 Aug 1999, Mats Wichmann wrote:

> This is not quite the same concept as snapshot filesystems, although you
> can certainly use it for reliable backups (quiescent filesystems!).  With a 
> spare
> disk you can even use lv and a floating mirror disk to help back up several 
> mirrored
> devices - attach it to one mirror, sync up, detach and backup, attach to 
> another
> mirror, sync, etc.


Now you're with me . . .


> 
> Snapshots (at least the concept that Veritas has described to the world) 
> let you
> freeze the state of a filesystem as a read-only image while the filesystem 
> itself
> remains live, but without breaking any mirrors and leaving yourself 
> temporarily in
> an unmirrored state.  All you really need is to be able to freeze a pointer 
> to the
> metadata, and set the FS into a state such that no disk block can be modified,
> instead it's always copied on write.  Requires suitable filesystem support, of
> course.  Those extra blocks are released only when you're done with the 
> snapshot.
> Snapshots can live for as long as you want, and there can be several of them
> active, as long as you have disk space that is.


Yeah, ever since Iposted that first message I feared a vxfs backlash when it wasn't what I intended.
There are some problems with Veritas concept of snapshots anyway, one of which is that on a vxfs
filesystem on a volume with dirty region logging, then snapping a mirror does not really leave the
new snap fs as "clean" as you might want it to.  This has to dowith the write ordering to the dirty
region log on the inital fs... you'l find on large filesystems (>100GB or so that I've noticed anyway), 
that active data on the primary
volume will cause so much writing to the volume log that the snap extent information hardly gets consulted
and the end result can be a snapshot backup of the active filesystem (since vxfs snapshot consults a changelog as
it performs the backup), not the snapped filesystem.  I hope
to avoid this problem in the Linux LVM by having some sort of volume log write ordering, or maybe including
the (for lack of a better term) dirty-region log as a mirror on the snap volume.  This is different from
the vxfs model mainly because my intention is to be able to essentially create snap mirrors of LVs
as most of the data I work with doesn't exist on filesystems anyway.

> 
> 

%                                                       %%%%%%%%%%
%%           S. Ryan Quick                               %%%%%%%%%
%%%           UNIX Systems Engineer                       %%%%%%%%
%%%%           Phaedo Consulting, Inc. -- Exec VP          %%%%%%%
%%%%%                                                       %%%%%%
%%%%%%         www.phaedo.com/ryan/  ryan@phaedo.com         %%%%%
%%%%%%%       ------------ PGP FingerPrint -------------      %%%%
%%%%%%%%  CF 19 6B BA 31 8E B8 8E  20 DF 4F 2B 2E 69 81 F5     %%%
%%%%%%%%%     ------------------------------------------        %%
%%%%%%%%%%                                                       %

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv

iQCVAwUBN8bkoPUYDAQiV+tNAQE7xAP/VNGd6GEIdMMFdx5FxxwxRe0Lm6QOnGOV
lj5/wnbx+zCf0XaVfavmZhWDAhmzXmYHCBcWx53PEMRI1sa3Pn/VONhQQtjW5h8+
ZkY7Qf2IZc/b+C9Z7abFa9OvI3Ub28HJkK67lCzfzG4Tsyuk2FS2dHX1ojdttEeb
mgC1DpeOByk=
=AMPT
-----END PGP SIGNATURE-----

Re: [linux-lvm] Revised petition WAS: LVM in stock kernel!?

[Shane Shrybman]

Hello People,

On Fri, 27 Aug 1999, Luca Berra wrote:

> i think that when wee agrre on the petition contents, we can
> put it on the web and mebbe have slashdot/lwn/freshmeat link
> the page.

Are we agreed on the petition contents?

Should we post to slashdot/lwn/freshmeat?

My only concern right now is time. It was a few weeks ago now that Linus
said that a "feature freeze" in 2.3 was coming. I think we need to get as
many supporters on our petition as possible and bring it to Linus' 
attention soon.

Shane

Re: [linux-lvm] Revised petition WAS: LVM in stock kernel!?

[Michael Ju. Tokarev]

Shane Shrybman wrote:
> PROS
[a lot of pros's skipped]
> 
> CONS
[]
What about adding new complecity to kernel code? Is this a cons?
Kernel already (maybe gone?) have some instabilities with fs,
saying some "Ooops" that are very hard to debug. Sorry if all
this Ooops are iliminated already, but info about them can be
found in many mailinglist archives (1997, 1998 yy at least).

And another two questions (maybe "politic"):

 - yes, Linux lacks now a great ability that exisit in other Unices.
   yes, Linux should have this ability.
   But why this should be linux-lvm? I do not know if other projects exists,
   and think that no, but is linux-lvm have exactly that things that really
   should have Linux? I like linux-lvm, but I like also Veritas, and like
   BSD's implementation... And all of them have different approaches!
   Sorry for this. One old good Russian proverb says that each orn compliments
   it's own morass.

 - look to solaris, for example -- it have lvm in a separate package (DiskSuite),
   that don't included kernel :!). This is an addon to os, and it doesn't do
   anything with kernel itself. Yes, I know about differences in kernel's architectures,
   and know little about Linux kernel internals, but linux have kernel modules!
   Is it possible to make lvm a separate package, like on Solaris? And not only
   lvm, but other things like drivers (!), fs's etc? Kernel should have base set
   of modules, and some sort of config files where others are listed, and as result
   there should be no need to recompile kernel at all! Yes, this is not an lvm
   question, but lvm-related. There are many kernel patches for different packages
   not included into stock kernel (like lvm ;), and each need this recompilation.
   Yes, some of them really _need_ recompilation, such as acl project, but some
   at least logically doesn't. So maybe ask Linus to work around pluggable modules
   instead of including lvm into kernel? This also seriously simplifies other parts
   of kernel. But I doesn't know if it is possible at all with current architecture.
   Microkernel? Hurd? ;)

> 
> Please feel free to edit and add your own points!
> 
> Shane

Regards,
  Michael.

Re: [linux-lvm] Revised petition WAS: LVM in stock kernel!?

[Luca Berra]

On Thu, Aug 26, 1999 at 06:28:59PM -0400, Shane Shrybman wrote:
> 
> I have added a few more points that I gleaned from this list. I have also
> taken the liberty of adding a SUPPORTERS section with people's names and
> email addresses. Please let me know if you have names to add or delete.
> 
> We need more SUPPORTERS! 

i think that when wee agrre on the petition contents, we can
put it on the web and mebbe have slashdot/lwn/freshmeat link
the page.

...
> - The "out of storage space" is a very common problem for users especially
>   new users. LVM makes resizing allocated space easier. This is perhaps
>   the most common problem I here about from new users.
it is also an enormous problem for big higly available systems

L.
-- 
Luca Berra -- bluca@comedia.it
    Communications Media & Services S.r.l.

[linux-lvm] Revised petition WAS: LVM in stock kernel!?

[rolf.aebi]

Shane writes:

> We need more SUPPORTERS!
>
> Please tell me explicitly if you would like to be added to the list, ( I
> don't feel comfortable adding names to a petition otherwise).

I think features like this are strongly needed to bring Linux into the real
big Datacenters.
I've been working with IBM's LVM on SP Systems in the xTB Region, and with
this
amount of Space, such a feature is IMHO a must.

For this reason you can add me also as a strong supporter of LVM for
Linux to the list.



Regards

Rolf
rolf.aebi@systor.com

[linux-lvm] Revised petition WAS: LVM in stock kernel!?

[Shane Shrybman]

I have added a few more points that I gleaned from this list. I have also
taken the liberty of adding a SUPPORTERS section with people's names and
email addresses. Please let me know if you have names to add or delete.

We need more SUPPORTERS! 

Please tell me explicitly if you would like to be added to the list, ( I
don't feel comfortable adding names to a petition otherwise).

PROS
- LVM is almost a necessity when managing large amounts of storage.
- it is one of the key enablers to open enterprise doors.
- Many unix people think that storage layout is one of the most difficult
  aspects of maintaining a system. LVM simply makes storage management
  much more flexible by allowing storage to be reallocated easily at
  anytime.
- Folks coming to Linux from other UNIXes which use an LVM (HP, AIX,
  Solaris, IRIX etc..) will be familiar and comfortable with LVM concepts
  and will more readily embrace the penguin.
- The "out of storage space" is a very common problem for users especially
  new users. LVM makes resizing allocated space easier. This is perhaps
  the most common problem I here about from new users.
- LVM is not a new concept and has been proven to be indispensible in
  other OSes, (ie. It is not just some hair-brained scheme that just makes
  things harder to learn and more complicated).
- LVM provides the information to check i/o bottlenecks in a more fine
  grained manner and enables the user to solve them.
- its implementation doesn't add much complexity to the
  block i/o layer (compared to for eg. MD) and therefore avoids
  instabilities.
- Opens the door for storage management GUIs that would make storage
  management easier for all users.
- Integration with IBM's ADSM backup allows Linux machines to be backed up
  "snapshot" style by simply syncing volumes and grabbing volume data.
- The ability to add a sort of volume log allows almost instant volume
  resyncing while maintaining an active data volume.
- The (unique) ability to use either physical disks or partitions (and
  even flat files via the loopback device) allows for a
  very flexible Volume Group makeup (e.g. I don't get stuck having to
  allocate all of that 18GB drive to a volume when I only
  need 4GB of it, etc.).  NOTE:  This does add some cons when it comes to
  deporting (exporting) volumes and migrating disks,
  but it should be easy enough to overcome.

CONS
- Using LVM is by definition adding a another logical layer for storage.
  Users not already familiar with an LVM will have to do some learning, or
  not use LVM.
- some cost in performance since there's an additional layer of
  translation before you get to the actual disk blocks....


SUPPORTERS
------------------------------------------------------------------
Heinz Mauelshagen	mauelsha@ez-darmstadt.telekom.de
S. Ryan Quick		ryan@phaedo.com
Shane Shrybman		shane@zeke.yi.org
Mike Manocchio		manocc@iname.com
Ernie Lim		elim@ern-e.org
Marcus Ruehmann		m.ruehmann@mail.isis.de
James Pattinson		jamesp@aethos.co.uk
Fernando Dammous	ferdam@internetcom.com.br
Pascal			pamvdam@ramoth.xs4all.nl
Ulrik De Bie		winmute@atlantique.venturi.net
Klaus Strebel		stb@ep-ag.com
Mark Adams		madams@jewels.com
Drew Smith		drew@winterland.mainland.ab.ca
Luca Berra		bluca@comedia.it
Jonny B.		brassow@lcse.umn.edu
Mats Wichmann		mats@laplaza.org
Mark Kolb		mkolb@srhs.org


Comments ?

Please feel free to edit and add your own points!

Shane