Re: [linux-lvm] Re: IBM to release LVM Technology to the Linux

Re: [linux-lvm] Re: IBM to release LVM Technology to the Linux

[Andreas Dilger]

Ben, you write:
> As for "logical extents", volume groups, etc. - there has been much
> discussion in IBM on this topic, and the concensus is that they are of
> little benefit, and are not needed under this architecture.  Furthermore,
> usability studies found that most users found volume groups to be very
> confusing and of little value.  As a result, this architecture specifically
> avoids them.

Having used both the AIX LVM, the Linux LVM, and the good-old DOS
partitions, I would have to disagree with your statement that logical
extents are of very little benefit.  One of the worst things to do
in a DOS-partitioned world is to resize the partitions themselves.
You always have to over-estimate the partition sizes in case you need
more space in the future, or add a whole new partition if you run out
of space in the existing partition.

The joy of using the existing LVMs is that you can have many
just-big-enough partitions, adding and removing them as desired, and
if they aren't big enough, you simply resize them to be big enough.
AIX has this at its very core - the package installer will expand /usr,
/var, /etc to be big enough for newly installed packages, rather than
simply letting the install fail because it ran out of space in one
filesystem even though there is enough space in the system as a whole.

Without dividing the disk into small chunks for allocation the way the
current LVM implementations do, we are back in the stone age, the same
way Fortran 66 is to C.  With old Fortran, you had to pre-allocate all of
your memory elements to be the maximum possible size because you couldn't
dynamically allocate memory at the correct size for the current need.
Nobody wants to go back to static arrays in Fortran (I hope ;-), in the
same way I don't want to go back to statically assigned partition sizes.

Using concatenation of whole partitions/disks (ala Sun DiskSuite or Linux MD
concat) really sucks, IMHO.  People don't always have whole disks sitting
around unused, and even if they do, it is again the case that you have to
allocate way too much space for what you need.  If you only want to add a
small amount of space to a filesystem, you will end up partitioning your
spare disk into many small chunks, and you will have a poor-man's logical
extent in the end.

Cheers, Andreas

Re: [linux-lvm] Re: IBM to release LVM Technology to the Linux

[Martin K. Petersen]

>>>>> "Andreas" == Andreas Dilger <adilger@turbolabs.com> writes:

Andreas> Having used both the AIX LVM, the Linux LVM, and the good-old
Andreas> DOS partitions, I would have to disagree with your statement
Andreas> that logical extents are of very little benefit.  One of the
Andreas> worst things to do in a DOS-partitioned world is to resize
Andreas> the partitions themselves.  You always have to over-estimate
Andreas> the partition sizes in case you need more space in the
Andreas> future, or add a whole new partition if you run out of space
Andreas> in the existing partition.

Andreas, you are preaching to the choir.  Partitions don't belong in
an LVM architecture at all.  They are a legacy thing which needs to go
away.

Also, I don't tend to agree with most of the infrastructure proposed
in the IBM whitepaper.  If IBM's intention is that this will be a
cross-OS LVM architecture, well then fine -- lots of abstractions are
obviously needed.

If it is supposed to be Linux specific, however, I don't see why one
would waste engineering resources implementing plug-ins for reading
Macintosh partitions types etc.  We already have an adequate framework
for that in the kernel.


The scheme I've been toying with over the past months:

 - Logical Disk = Either partition or whole disk.

 - The Logical Disk provides allocation space for extents.

 - Extents are allocated on the available logical disks based upon
   heuristics in the feature set/system administrator preferences.

 - Logical Volume consists of one or more extents accessed through one
   or more feature sets (RAID0, RAID1, RAID5, encryption, whatever).

The extents can be of varying size depending on the application.  A 30
GB RAID5 LV could be constructed from 4 x 10 GB extents on 4 different
physical disks + a 10 GB hot spare extent on a fifth disk, for
instance.

-- 
Martin K. Petersen      Principal Linux Consultant, Storage
http://mkp.net/         Linuxcare, Inc.

Re: [linux-lvm] Re: IBM to release LVM Technology to the Linux

[benr]

Andreas,

>Ben, you write:
>> As for "logical extents", volume groups, etc. - there has been much
>> discussion in IBM on this topic, and the concensus is that they are of
>> little benefit, and are not needed under this architecture.
Furthermore,
>> usability studies found that most users found volume groups to be very
>> confusing and of little value.  As a result, this architecture
specifically
>> avoids them.

>Having used both the AIX LVM, the Linux LVM, and the good-old DOS
>partitions, I would have to disagree with your statement that logical
>extents are of very little benefit.  One of the worst things to do
>in a DOS-partitioned world is to resize the partitions themselves.
>You always have to over-estimate the partition sizes in case you need
>more space in the future, or add a whole new partition if you run out
>of space in the existing partition.

>The joy of using the existing LVMs is that you can have many
>just-big-enough partitions, adding and removing them as desired, and
>if they aren't big enough, you simply resize them to be big enough.
>AIX has this at its very core - the package installer will expand /usr,
>/var, /etc to be big enough for newly installed packages, rather than
>simply letting the install fail because it ran out of space in one
>filesystem even though there is enough space in the system as a whole.

>Without dividing the disk into small chunks for allocation the way the
>current LVM implementations do, we are back in the stone age, the same
>way Fortran 66 is to C.  With old Fortran, you had to pre-allocate all of
>your memory elements to be the maximum possible size because you couldn't
>dynamically allocate memory at the correct size for the current need.
>Nobody wants to go back to static arrays in Fortran (I hope ;-), in the
>same way I don't want to go back to statically assigned partition sizes.

>Using concatenation of whole partitions/disks (ala Sun DiskSuite or Linux
MD
>concat) really sucks, IMHO.  People don't always have whole disks sitting
>around unused, and even if they do, it is again the case that you have to
>allocate way too much space for what you need.  If you only want to add a
>small amount of space to a filesystem, you will end up partitioning your
>spare disk into many small chunks, and you will have a poor-man's logical
>extent in the end.

>Cheers, Andreas

I think the issue here is not the partitions on the disks themselves but
the resizing of volumes.  Under the LVMS outlined in the white paper,
resizing a volume is not as clear cut as it is in the existing LVMs.  Under
the LVMS, a volume consists of one or more logical partitions.  These
logical partitions are joined together to form the volume by "Features".
It is the "Features" in use on a volume which determine if the volume can
be expanded or contracted, and the method by which the expansion or
contraction will be performed.  There are two basic methods by which a
volume can be expanded: add logical partitions to the volume or expand one
or more of the logical partitions which are already part of the volume.
Similarly, there are two methods to shrink a volume: remove logical
partitions from the volume, or shrink one or more of the logical partitions
which are already a part of the volume.  Which method is used (if not both)
is determined by the "Features" used to form the volume.  Thus, under the
LVMS, it is possible to create volumes which can be resized, as well as
volumes which can NOT be resized.  Whether or not a volume can be resized
is under the control of the user, who selects which "Features" to use on a
volume when that volume is created.  Therefore, if a user wants
just-big-enough volumes that can be resized as desired, they can do so by
choosing "features" which allow volumes to be resized when they create the
volumes.

Of course, this brings us to the question of: "Are there times when a user
may want to create a volume which can NOT be resized?"  The answer to this
question is yes.  There are several applications of this which mainly come
to play in high security environments, such as are found in the military
and most governments. ;-)  I am limited as to what I can say in this
regard, but the basic idea is that, on a high security system, classified
information is restricted to approved devices.  Volumes created on these
devices to hold classified information are normally set up to be
non-resizeable in order to prevent a volume from being expanded
(accidentally or otherwise) to use a non-approved device.  Cases like this
are easily handled by the LVMS through the use of a "feature" plug-in.

One other interesting aspect of the elimination of volume groups is that
quorum support is not needed.  Under the LVMS, when a drive fails, only the
volumes which actually had partitions on the failed drive are affected, not
an entire volume group.  Quorum support is an attempt to address this
shortcoming in volume groups, but since the LVMS does not use volume
groups, it is not needed by the LVMS.

Regards,

Ben

Re: [linux-lvm] Re: IBM to release LVM Technology to the Linux

[benr]

Martin,

Welcome to the discussion, and thanks for sharing your opinion.

>>>>> "Andreas" == Andreas Dilger <adilger@turbolabs.com> writes:

Andreas> Having used both the AIX LVM, the Linux LVM, and the good-old
Andreas> DOS partitions, I would have to disagree with your statement
Andreas> that logical extents are of very little benefit.  One of the
Andreas> worst things to do in a DOS-partitioned world is to resize
Andreas> the partitions themselves.  You always have to over-estimate
Andreas> the partition sizes in case you need more space in the
Andreas> future, or add a whole new partition if you run out of space
Andreas> in the existing partition.

Martin>Andreas, you are preaching to the choir.  Partitions don't belong in
Martin>an LVM architecture at all.  They are a legacy thing which needs to
go
Martin>away.

What is a partition?  By definition, a partition is a contiguous block of
disk space.

What is an extent?  By definition, an extent is a contiguous block of disk
space.

What is the difference between them?  Besides the names, nothing in and of
themselves.  What's different is how they are managed, specifically the
structures and rules used to manage them.

Martin>Also, I don't tend to agree with most of the infrastructure proposed
Martin>in the IBM whitepaper.  If IBM's intention is that this will be a
Martin>cross-OS LVM architecture, well then fine -- lots of abstractions
are
Martin>obviously needed.

Our customers have asked for a migration path to Linux from their existing
platforms.  Migration is made much easier and much less expensive when the
new platform can read and write to the volumes/partitions/etc. used by the
old platform.  Furthermore, most of our customers will require a testing
period where the new platform and the old platform are compared on the same
hardware using the same datasets.  Again, the ability of the new platform
to use the volumes/partitions/etc. of the old platform can greatly speed
the testing process while reducing costs.  Finally, an LVMS based upon the
architecture in the white paper would, with the proper plug-in modules,
ease migration from several platforms (both IBM and non-IBM) to Linux by
allowing Linux to use the volumes/partitions/etc. of these platforms.

As far as being a cross-OS LVM architecture, this is true.  This
architecture was designed with the idea of being OS neutral where possible,
and is being considered for implementation on other IBM platforms.

Martin>If it is supposed to be Linux specific, however, I don't see why one
Martin>would waste engineering resources implementing plug-ins for reading
Martin>Macintosh partitions types etc.  We already have an adequate
framework
Martin>for that in the kernel.

The MacIntosh partitioning scheme was merely an example.  With the proper
plug-ins, an LVMS based upon the architecture in the white paper would be
able to access and manipulate logical volumes (and volume groups) created
by AIX, for example.  Again, though, implementing support for other OS
partitioning schemes and logical volume management schemes aids in
migration to Linux.

Another thing to remember is that users want power without risk.  This is
especially true in the corporate world.  To make it there, Linux needs a
very powerful, flexible logical volume management system which minimizes
the risk of losing data.  This calls for an architecture which integrates
all aspects of volume/disk management into a single, easy to use entity.
All processes which could be automated should be automated to prevent
"accidents", such as the improper shrinking of a volume containing data.
Right now it is rather easy to accidentally shrink a volume before
shrinking the filesystem on the volume, or to shrink the filesystem on the
volume by the wrong amount.  Is fdisk volume group aware (have not tried
this yet)?  If it isn't, a user could make a mistake and delete a partition
which belongs to a volume group.  The current system has holes in it, and
these holes need to be plugged before Linux can be a major player in the
corporate world.  These holes can be plugged in a patch work fashion, or
they can be eliminated by adopting an architecture (not necessarily the one
in the white paper) in which they don't exist or can't occur.

Martin>The scheme I've been toying with over the past months:
Martin>
Martin> - Logical Disk = Either partition or whole disk.
Martin>
Martin> - The Logical Disk provides allocation space for extents.
Martin>
Martin> - Extents are allocated on the available logical disks based upon
Martin>   heuristics in the feature set/system administrator preferences.
Martin>
Martin> - Logical Volume consists of one or more extents accessed through
one
Martin>   or more feature sets (RAID0, RAID1, RAID5, encryption, whatever).
Martin>
Martin>The extents can be of varying size depending on the application.  A
30
Martin>GB RAID5 LV could be constructed from 4 x 10 GB extents on 4
different
Martin>physical disks + a 10 GB hot spare extent on a fifth disk, for
Martin>instance.

I don't understand your example.  Change the word extent to partition and
you have:

 A 30 GB RAID5 LV could be constructed from 4 x 10 GB partitions on 4
different
physical disks + a 10 GB hot spare partition on a fifth disk, for instance.

This is exactly what you would have under the LVMS described in the white
paper.  Your example shows nothing which could not be done through the LVMS
architecture with partitions.  Am I missing something here?


Regards,

Ben

Re: [linux-lvm] Re: IBM to release LVM Technology to the Linux

[Dale Kemp]

> Another thing to remember is that users want power without risk.  This is
> especially true in the corporate world.  To make it there, Linux needs a
> very powerful, flexible logical volume management system which minimizes
> the risk of losing data.  This calls for an architecture which integrates
> all aspects of volume/disk management into a single, easy to use entity.
> All processes which could be automated should be automated to prevent
> "accidents", such as the improper shrinking of a volume containing data.
> Right now it is rather easy to accidentally shrink a volume before
> shrinking the filesystem on the volume, or to shrink the filesystem on the
> volume by the wrong amount.  Is fdisk volume group aware (have not tried
> this yet)?  If it isn't, a user could make a mistake and delete a partition
> which belongs to a volume group.  The current system has holes in it, and
> these holes need to be plugged before Linux can be a major player in the
> corporate world.  These holes can be plugged in a patch work fashion, or
> they can be eliminated by adopting an architecture (not necessarily the one
> in the white paper) in which they don't exist or can't occur.

% man e2fsadm

DESCRIPTION
       e2fsadm allows resizing of a logical volume  (see  lvm(8),
       lvcreate(8))  containing  an unmounted ext2 filesystem and
       then extending the filesystem by  resize2fs(8)  afterwards
       or  reducing  the  filesystem  first and then reducing the
       logical volume afterwards.

First thing is Linux-LVM is still evolving and will only get better. Now IBM
and SGI have their own volume management systems which is fine, and
porting them to Linux can only be a good thing too. At the end of the day
its the users in the community that choose. Now its in the community and
IBM users interest for IBM to port AIX systems to Linux, so people can simply
install Linux and use there existing AIX hard drives. The same goes for SGI.
And work is already underway with JFS and XFS for example.
I actually like the system being evolved by Linux-LVM since it follows the
Unix
philosophy do one thing and to it well (the opposite of Micr$oft).

-- Dale.

Re: [linux-lvm] Re: IBM to release LVM Technology to the Linux

[Martin K. Petersen]

>>>>> "Ben" == benr <benr@us.ibm.com> writes:

[Musings deleted]

Ben> This is exactly what you would have under the LVMS described in
Ben> the white paper.  Your example shows nothing which could not be
Ben> done through the LVMS architecture with partitions.  Am I missing
Ben> something here?

I am advocating:

1. Using existing partitioning schemes to encapsulate logical disks.

   This is only relevant in the migration case and if people want to
   test LVMS on a few disks that are already partitioned.  If your
   system has hundreds of disks connected, you'll use a 1:1 physical
   to logical disk mapping anyway.

2. Avoid using existing partitioning schemes to encapsulate logical
   partitions/extents.

-- 
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.

Re: [linux-lvm] Re: IBM to release LVM Technology to the Linux

[hpuxadm]

After seeing a few comments left by various users on this subject, I
would like to throw in my two cents that from an "admin" perspective,
this type of effort from a major vendor can only be a good thing.
However, just like anyone else who has watched the "major"
vendors(Compaq, HP, IBM) embrace Microsoft in the early 1990's, I
begin to wonder what the goal is with this project.  Is IBM's
implementation of LVM going to remain free(gasp!), or is the goal to
start beta testing on Linux now only to offer LVM at a premium price
later?  LVM solutions that are offered by IBM, SUN, and HP are all
excellent!  However, you pay for them big time when you start getting
into advanced volume management issues.  I have looked over the
datasheet that your website provides and am impressed with what you
are doing technically. What I am curious about is what will happen
once your implementation evolves to a "production ready" status.  I
guess what I am more or less asking is, am I wasting my time following
IBM's implementation of LVM due to the fact that once it does leave
the development stage I will end up paying thousands of dollars per
seat for it?

Thoughts?

- Christopher Briggs
  consult@unixadministrator.com

> > Another thing to remember is that users want power without risk.
This is
> > especially true in the corporate world.  To make it there, Linux
needs a
> > very powerful, flexible logical volume management system which
minimizes
> > the risk of losing data.  This calls for an architecture which
integrates
> > all aspects of volume/disk management into a single, easy to use
entity.
> > All processes which could be automated should be automated to
prevent
> > "accidents", such as the improper shrinking of a volume containing
data.
> > Right now it is rather easy to accidentally shrink a volume before
> > shrinking the filesystem on the volume, or to shrink the
filesystem on the
> > volume by the wrong amount.  Is fdisk volume group aware (have not
tried
> > this yet)?  If it isn't, a user could make a mistake and delete a
partition
> > which belongs to a volume group.  The current system has holes in
it, and
> > these holes need to be plugged before Linux can be a major player
in the
> > corporate world.  These holes can be plugged in a patch work
fashion, or
> > they can be eliminated by adopting an architecture (not
necessarily the one
> > in the white paper) in which they don't exist or can't occur.
>
> % man e2fsadm
>
> DESCRIPTION
>        e2fsadm allows resizing of a logical volume  (see  lvm(8),
>        lvcreate(8))  containing  an unmounted ext2 filesystem and
>        then extending the filesystem by  resize2fs(8)  afterwards
>        or  reducing  the  filesystem  first and then reducing the
>        logical volume afterwards.
>
> First thing is Linux-LVM is still evolving and will only get better.
Now IBM
> and SGI have their own volume management systems which is fine, and
> porting them to Linux can only be a good thing too. At the end of
the day
> its the users in the community that choose. Now its in the community
and
> IBM users interest for IBM to port AIX systems to Linux, so people
can simply
> install Linux and use there existing AIX hard drives. The same goes
for SGI.
> And work is already underway with JFS and XFS for example.
> I actually like the system being evolved by Linux-LVM since it
follows the
> Unix
> philosophy do one thing and to it well (the opposite of Micr$oft).
>
> -- Dale.
>
>

Re: [linux-lvm] Re: IBM to release LVM Technology to the Linux

[Jens Benecke]

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

On Fri, Jun 23, 2000 at 07:52:00AM -0500, hpuxadm@choice.net wrote:

> After seeing a few comments left by various users on this subject, I
> would like to throw in my two cents that from an "admin" perspective,
> this type of effort from a major vendor can only be a good thing.

Agreed.

> However, just like anyone else who has watched the "major"
> vendors(Compaq, HP, IBM) embrace Microsoft in the early 1990's, I begin
> to wonder what the goal is with this project.  Is IBM's implementation of
> LVM going to remain free(gasp!), or is the goal to start beta testing on

Apparently. The white paper said something to the extent that "if any code
is released, it will be under the GPL". That looks as though they don't
want to keep themselves any loopholes open, like Sun's "you can do anything
with our code, except touch it" SCS licence (SCSL).

> Linux now only to offer LVM at a premium price later?  LVM solutions that
> are offered by IBM, SUN, and HP are all excellent!  However, you pay for

If they are compatible :)

> ready" status.  I guess what I am more or less asking is, am I wasting my
> time following IBM's implementation of LVM due to the fact that once it
> does leave the development stage I will end up paying thousands of
> dollars per seat for it?

You might, if you want to receive any level for support & services. I
guess, what IBM is aiming at is that they will offer a Linux migration path
for their customers with their LVM. The source will be freely available, so
they will participate in the giant open source mindshare and their
knowledge will be applied elsewhere, but I for one would hesitate to trust
my company's precious data to a volume manager I compiled and patched
together myself - what if I used a wrong compiler (switch), or whatever?

Of course, this opens the door for third party support people who patch
their own LVM and offer support (and that is a Good Thing(tm)). IBM will
have to compete with them (i.e.  offer competetive prices for one thing) so
you cannot really be held hostage by anyone's support department.
 

-- 
"The PROPER way to handle HTML postings is to cancel the article, then hire
a killer to kill the poster, his wife and kids, and fuck his dog and smash
his computer into little bits. Anything more is just extremism." - ptomblin

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

Re: [linux-lvm] Re: IBM to release LVM Technology to the Linux

[benr]

Christopher,

Welcome to the discussion!  To answer your question, if the Linux Community
is interested in the LVMS outlined in the white paper, then IBM will
release code (under the GPL!) to begin moving this technology to Linux.  I
suspect that IBM will also dedicate some resources to assist in moving this
technology to Linux as that will expedite the process.  Right now, though,
we are trying to educate the Linux Community about our LVMS Architecture so
that the Linux Community can make an informed decision as to whether they
want this technology or not.  Of course, we hope they do - the technology
has many benefits.  However, I would like to say that a decision by the
Linux Community to accept this technology does not mean that the current
LVM will be discarded.  This is not an either/or decision.  While the LVMS
solves certain problems for IBM and its customers, IBM and its customers
are not the only users of Linux.  I suspect that many users coming from the
UNIX world to Linux will be more comfortable using the current LVM because
it is based upon the standard UNIX approach to logical volume management.
Similarly, users coming from the DOS/Windows/OS2 world to Linux will
probably be more comfortable using the LVMS as that employs many of the
concepts that they are already familiar with.  Thus, I think that there is
a place for both the current LVM and the LVMS.  Looking down the road, I
see both the current LVM and the LVMS co-existing for a period of time,
with development on each continuing, with each adopting the best ideas of
the other.  Eventually, I see them merging in some fashion. but when this
occurs and what the final result is, is beyond the ability of my crystal
ball to see.  The one thing I can see, though, is that whatever the final
result is, it will be open source and under the GPL! :-)

Regards,

Ben


hpuxadm@choice.net@msede.com on 06/23/2000 07:52:00 am

Sent by:  owner-linux-lvm@msede.com


To:   Dale Kemp <dale@inet.net.nz>
cc:   Linux LVM mailing list <linux-lvm@msede.com>
Subject:  Re: [linux-lvm] Re: IBM to release LVM Technology to the Linux



After seeing a few comments left by various users on this subject, I
would like to throw in my two cents that from an "admin" perspective,
this type of effort from a major vendor can only be a good thing.
However, just like anyone else who has watched the "major"
vendors(Compaq, HP, IBM) embrace Microsoft in the early 1990's, I
begin to wonder what the goal is with this project.  Is IBM's
implementation of LVM going to remain free(gasp!), or is the goal to
start beta testing on Linux now only to offer LVM at a premium price
later?  LVM solutions that are offered by IBM, SUN, and HP are all
excellent!  However, you pay for them big time when you start getting
into advanced volume management issues.  I have looked over the
datasheet that your website provides and am impressed with what you
are doing technically. What I am curious about is what will happen
once your implementation evolves to a "production ready" status.  I
guess what I am more or less asking is, am I wasting my time following
IBM's implementation of LVM due to the fact that once it does leave
the development stage I will end up paying thousands of dollars per
seat for it?

Thoughts?

- Christopher Briggs
  consult@unixadministrator.com

> > Another thing to remember is that users want power without risk.
This is
> > especially true in the corporate world.  To make it there, Linux
needs a
> > very powerful, flexible logical volume management system which
minimizes
> > the risk of losing data.  This calls for an architecture which
integrates
> > all aspects of volume/disk management into a single, easy to use
entity.
> > All processes which could be automated should be automated to
prevent
> > "accidents", such as the improper shrinking of a volume containing
data.
> > Right now it is rather easy to accidentally shrink a volume before
> > shrinking the filesystem on the volume, or to shrink the
filesystem on the
> > volume by the wrong amount.  Is fdisk volume group aware (have not
tried
> > this yet)?  If it isn't, a user could make a mistake and delete a
partition
> > which belongs to a volume group.  The current system has holes in
it, and
> > these holes need to be plugged before Linux can be a major player
in the
> > corporate world.  These holes can be plugged in a patch work
fashion, or
> > they can be eliminated by adopting an architecture (not
necessarily the one
> > in the white paper) in which they don't exist or can't occur.
>
> % man e2fsadm
>
> DESCRIPTION
>        e2fsadm allows resizing of a logical volume  (see  lvm(8),
>        lvcreate(8))  containing  an unmounted ext2 filesystem and
>        then extending the filesystem by  resize2fs(8)  afterwards
>        or  reducing  the  filesystem  first and then reducing the
>        logical volume afterwards.
>
> First thing is Linux-LVM is still evolving and will only get better.
Now IBM
> and SGI have their own volume management systems which is fine, and
> porting them to Linux can only be a good thing too. At the end of
the day
> its the users in the community that choose. Now its in the community
and
> IBM users interest for IBM to port AIX systems to Linux, so people
can simply
> install Linux and use there existing AIX hard drives. The same goes
for SGI.
> And work is already underway with JFS and XFS for example.
> I actually like the system being evolved by Linux-LVM since it
follows the
> Unix
> philosophy do one thing and to it well (the opposite of Micr$oft).
>
> -- Dale.
>
>

Re: [linux-lvm] Re: IBM to release LVM Technology to the Linux

[Paul Jakma]

On Fri, 23 Jun 2000 benr@us.ibm.com wrote:

> 
> 
> Christopher,
> 
> Welcome to the discussion!  To answer your question, if the Linux
> Community is interested in the LVMS outlined in the white paper,
> then IBM will release code (under the GPL!) to begin moving this
> technology to Linux.  I suspect that IBM will also dedicate some
> resources to assist in moving this technology to Linux as that
> will expedite the process. 

would it not perhaps be more efficient and more purposeful if rather
than releasing IBM specific code which will not 'drop-in' to linux,
IBM were instead to use their knowledge gained from IBM LVM to assist
with improving the current Linux LVM?

regards,
-- 
Paul Jakma	paul@clubi.ie
PGP5 key: http://www.clubi.ie/jakma/publickey.txt
-------------------------------------------
Fortune:
I don't mind what Congress does, as long as they don't do it in the
streets and frighten the horses.
		-- Victor Hugo

Re: [linux-lvm] Re: IBM to release LVM Technology to the Linux

[Dale Kemp]

> > Welcome to the discussion!  To answer your question, if the Linux
> > Community is interested in the LVMS outlined in the white paper,
> > then IBM will release code (under the GPL!) to begin moving this
> > technology to Linux.  I suspect that IBM will also dedicate some
> > resources to assist in moving this technology to Linux as that
> > will expedite the process.
>
> would it not perhaps be more efficient and more purposeful if rather
> than releasing IBM specific code which will not 'drop-in' to linux,
> IBM were instead to use their knowledge gained from IBM LVM to assist
> with improving the current Linux LVM?
>

Not only this, but SGI are looking at releasing their volume management
system as well. Now does the user really want three (or more) logical
volume management systems, all with different toolsets and kernel
modules? The best solution is if SGI, IBM and Linux-LVM get together
and produce one very powerful and stable LVM system, this would be
a test in itself to get this group together. Don't forget the all
important
users out there.
SGI and IBM are supporting linux for many reasons:

    - Users want Linux
    - Linux is becoming the de facto standard. For all those years the
commercial
       Unix(tm) vendors were heading off in there own directions, all
different
       filesystems, volume management... Not good for Unix overall and
not good
       for the public. [Don't tell me they are thinking of doing this
again!!]
    - The Unix sector is now smaller, and supporting and extending an OS
is becoming
       more and more costly and complex; better off with one common base
: Linux.
    - Uses want to use existing vendors hardware (like SGI and IBM) and
moving
        from IRIX or AIX to Linux needs to be as painless as possible.

So what should SGI, IBM (and others) aim's be? Simple, allow the users
to carry
on doing the things they could do before, or provide another effective
solution.
Now are we going to see SGI's XFS sitting on top of IBM's LVMS!? Or can
only
JFS sit on IBM-LVMS, and XFS only sit on XVM!?
Wouldn't it be much nicer to see XFS, JFS, EXT3, ReiserFS all sitting on
top
of Linux-LVM; and for that technology to support the advanced features
needed by these filesystems?
SGI and IBM should be getting stuck in now and helping LLVM, its best
for their
users and best for them.

SGI-XVM and IBM-LVMS could even be modules that plug into LLVM base that

provide functionality for their existing users.

eg. Something like...

    # insmod lvm
    # insmod lvm-ibm
    # ibm_addpv -add /dev/sdg5    <-- IBM AIX disc.
    # pvscan
    pvscan -- active PV(IBM-LVMS) "/dev/sdg5" is in no VG [12.6 GB]
    pvscan -- inactive PV "/dev/hda5" is in no VG [5 GB]
    # ibm_addvg ibm_vg /dev/sdg5
    # ibm_addlv ibm_lv ibm_vg
    # mount -t JFS /dev/ibm_vg/ibm_lv /mnt/ibm
    # jfs_tool -fancy_lvms_option /mnt/ibm
    # insmod lvm-sgi
    # sgi_addpv /dev/sdh3 /dev/sdh5 <-- SGI IRIX disc.
    # sgi_addvg sgi_vg /dev/sdh3 /dev/sdh5
    # sgi_addlv sgi_lv sgi_vg
    # pvscan
    pvscan -- active PV(IBM-LVMS) "/dev/sdg5" is in no ibm_vg [12.6 GB]
    pvscan -- inactive PV "/dev/hda5" is in no VG [5 GB]
    pvscan -- active PV(SGI-XFS) "/dev/sdh3" is in sgi_vg [10.1 GB]
    pvscan -- active PV(SGI-XFS) "/dev/sdh5" is in sgi_vg [18 GB]
    # mount -t XFS /dev/sgi_vg/sgi_lv /mnt/sgi
    # xfs_tool -fancy_xvm_option /mnt/sgi
    # resizefs -s+50M /mnt/ibm
    # resizefs -s+50M /mnt/sgi
    # lvscan
    <shows all LVs including `mapped' LVMS and XVM>
    # umount /mnt/sgi
    # vgremove /dev/sgi_vg
    <note there will be realistic restrictions...>
    # vgcreate new_vg /dev/sdg5 /dev/sdh3
    Error: Different PV types can not exist in the same VG.
    They contain different partition formats and/or file systems.

SGI and IBM please consider this, instead of releasing code that doesn't
`drop-in'
to Linux.

-- Dale (dale@sclnz.com)

Re: [linux-lvm] Re: IBM to release LVM Technology to the Linux

[S. Ryan Quick]

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

On Sat, 24 Jun 2000, Dale Kemp wrote:

> Not only this, but SGI are looking at releasing their volume management
> system as well. Now does the user really want three (or more) logical
> volume management systems, all with different toolsets and kernel
> modules? The best solution is if SGI, IBM and Linux-LVM get together
> and produce one very powerful and stable LVM system, this would be
> a test in itself to get this group together. Don't forget the all
> important
> users out there.
> SGI and IBM are supporting linux for many reasons:

June 30 throws VERITAS Volume Manager into the mix as well . . . I'm scheduled to receive beta code for
Redhat/Debian . . .  

Ryan

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

iQCVAwUBOVT47vUYDAQiV+tNAQE1qgP+KGvst5KQhS1nbm27ynzawd3QBj7rnYTO
a7L9xYLRVh45GyopZXIy35bPFvMIOMgMuQFsYwwzbHoxmoE5VIOoaZtYCV7j3nyN
VXhgLlKVfKTXxrfI6ye+WgMfgiW6CU/vvGgRqCkM8u0QyNA7yfOTmk61aEkRFf5/
Lnl4FDHnwkE=
=E+J2
-----END PGP SIGNATURE-----

Re: [linux-lvm] Re: IBM to release LVM Technology to the Linux

[Dale Kemp]

> > Not only this, but SGI are looking at releasing their volume management
> > system as well. Now does the user really want three (or more) logical
> > volume management systems, all with different toolsets and kernel
> > modules? .....
>
> June 30 throws VERITAS Volume Manager into the mix as well . . . I'm scheduled to receive beta code for
> Redhat/Debian . . .
>
> Ryan
>

Ok, now we have four volume managers. By the looks of it VERITAS also has its own
filesystem and RAID code, and utilities. Question is what level of mixing is allowed?
Will this be open source / (L)GPL code ?

-- Dale.

Re: [linux-lvm] Re: IBM to release LVM Technology to the Linux

[Martin K. Petersen]

>>>>> "Dale" == Dale Kemp <dale@inet.net.nz> writes:

Dale> Not only this, but SGI are looking at releasing their volume
Dale> management system as well. 

Porting it, yes.  It is a prerequisite for CXFS.  Whether XVM will be
released as GPL has yet to be determined.


Dale> Now does the user really want three (or more) logical volume
Dale> management systems, all with different toolsets and kernel
Dale> modules? 

There are many different approaches to volume management.  Neither of
the three in question are similar enough to make integration trivial.

I suspect the users will have several LVMs to choose from in the
future.  Just as it is the case with file systems.  This has the
advantage that the user can choose whatever implementation solves
his/her problems.


Dale> Now are we going to see SGI's XFS sitting on top of IBM's LVMS!?

If IBM's LVMS will be using a kiobuf-based request scheme instead of
buffer_heads, yes.


Dale> Wouldn't it be much nicer to see XFS, JFS, EXT3, ReiserFS all
Dale> sitting on top of Linux-LVM; 

We'll certainly do our best to make sure XFS will work with all LVMs.

Heinz' implementation doesn't quite cut it for all purposes, however.
Neither does any of the other volume managers out there.

-- 
Martin K. Petersen      Principal Linux Consultant, Linuxcare, Inc.
http://mkp.net/         SGI XFS, Linux/PA-RISC, GNOME

RE: [linux-lvm] Re: IBM to release LVM Technology to the Linux

[Wilson, Eric]

I have to agree with Dale on this. So far the Linux LVM implementation seems
less than "Enterprise server mission critical." I don't mean to seem harsh or
negative, but my person life mission is to replace NT with Linux in every
instance possible. To widen the usage of Linux, Linux MUST be seen as reliable,
mission critical, but also easy to get it that way and keep it that way. (for
the point and click boys)

I will openly admit to being in love with the AIX LVM. the reasons are really
quite simple: A database server running several Terabytes of data can easily be
massaged without  fear of screwup or failure. The LINUX LVM must adhere to these
same all or nothing, rock solid philosophies to crush Microsoft. 

I realize I'm preaching to the choir, but Dale's primary premise holds true: To
get Linux and it's LVM out of the Uni. or LAB and into the Enterprise
datacenter; it must be foolproof.

  

Cheers;

> Eric Wilson
> IBM Certified AIX & SP Systems Support Specialist
> 
> Anheuser-Busch Companies, Inc.
> 
> One Busch Place
> 1CC-8
> St. Louis, MO 
> 
> Office		314.632.6653
> Mobile		314.495.4010
> Pager		314.670.0367
> 
> email		eric.wilson@anheuser-busch.com
> 
> 
> E!
> 
> 
> 
> 
> -----Original Message-----
> From:	Dale Kemp [SMTP:dale@inet.net.nz]
> Sent:	Thursday, June 22, 2000 8:24 PM
> To:	Linux LVM mailing list
> Subject:	Re: [linux-lvm] Re: IBM to release LVM Technology to the Linux
> 
> > Another thing to remember is that users want power without risk.  This is
> > especially true in the corporate world.  To make it there, Linux needs a
> > very powerful, flexible logical volume management system which minimizes
> > the risk of losing data.  This calls for an architecture which integrates
> > all aspects of volume/disk management into a single, easy to use entity.
> > All processes which could be automated should be automated to prevent
> > "accidents", such as the improper shrinking of a volume containing data.
> > Right now it is rather easy to accidentally shrink a volume before
> > shrinking the filesystem on the volume, or to shrink the filesystem on the
> > volume by the wrong amount.  Is fdisk volume group aware (have not tried
> > this yet)?  If it isn't, a user could make a mistake and delete a partition
> > which belongs to a volume group.  The current system has holes in it, and
> > these holes need to be plugged before Linux can be a major player in the
> > corporate world.  These holes can be plugged in a patch work fashion, or
> > they can be eliminated by adopting an architecture (not necessarily the one
> > in the white paper) in which they don't exist or can't occur.
> 
> % man e2fsadm
> 
> DESCRIPTION
>        e2fsadm allows resizing of a logical volume  (see  lvm(8),
>        lvcreate(8))  containing  an unmounted ext2 filesystem and
>        then extending the filesystem by  resize2fs(8)  afterwards
>        or  reducing  the  filesystem  first and then reducing the
>        logical volume afterwards.
> 
> First thing is Linux-LVM is still evolving and will only get better. Now IBM
> and SGI have their own volume management systems which is fine, and
> porting them to Linux can only be a good thing too. At the end of the day
> its the users in the community that choose. Now its in the community and
> IBM users interest for IBM to port AIX systems to Linux, so people can simply
> install Linux and use there existing AIX hard drives. The same goes for SGI.
> And work is already underway with JFS and XFS for example.
> I actually like the system being evolved by Linux-LVM since it follows the
> Unix
> philosophy do one thing and to it well (the opposite of Micr$oft).
> 
> -- Dale.
> 

Re: [linux-lvm] Re: IBM to release LVM Technology to the Linux

[Dale Kemp]

"Wilson, Eric" wrote:

> I have to agree with Dale on this. So far the Linux LVM implementation seems
> less than "Enterprise server mission critical." I don't mean to seem harsh or
> negative, but my person life mission is to replace NT with Linux in every
> instance possible. To widen the usage of Linux, Linux MUST be seen as reliable,
> mission critical, but also easy to get it that way and keep it that way. (for
> the point and click boys)
>
> I will openly admit to being in love with the AIX LVM. the reasons are really
> quite simple: A database server running several Terabytes of data can easily be
> massaged without  fear of screwup or failure. The LINUX LVM must adhere to these
> same all or nothing, rock solid philosophies to crush Microsoft.
>
> I realize I'm preaching to the choir, but Dale's primary premise holds true: To
> get Linux and it's LVM out of the Uni. or LAB and into the Enterprise
> datacenter; it must be foolproof.

Hi Eric,

I think you mean "Ben" not "Dale" in the above reply? You could just as easily
apply your "Enterprise server mission critical" badge to the whole on Linux, but
the facts are Linux is moving into these areas even with the "Uni. or LAB"
development process. I agree with everything else you say, stability is one of the
main things that Linux has over NT. I've used NT for a short period of time and
it wasn't a pleasant experience, it crashed four times just trying to install it.
And
people treat this as a "enterprise level" system !?!

Looking at the Linux VFS (Virtual FileSystem) seems to show up some problems,
for example I was more than surprised to find a big union with all the inode types
from every kind of filesystem in Linux. And yet there is still a call to register a
filesystem
with VFS. VFS is certainly not abstract. Any good OO programmer would have never
done it this way. Maybe we need SGIs Irix/vfs system more than we
need their XVM. See the white paper at SGI - "Porting the SGI XFS
File System to Linux", for more on this.
Linux VFS should know nothing about other filesystems until its told about them,
for example when you insert a filesystem module into the kernel.
[ Sorry this is a bit off topic for this list, but I feel its still important
to the overall linux filesystem itself. ]

From File: fs.h

struct inode {
        struct list_head        i_hash;
        struct list_head        i_list;
        struct list_head        i_dentry;

        unsigned long           i_ino;
        unsigned int            i_count;
        kdev_t                  i_dev;
        umode_t                 i_mode;
        nlink_t                 i_nlink;
        uid_t                   i_uid;
        gid_t                   i_gid;
        kdev_t                  i_rdev;
        loff_t                  i_size;
        time_t                  i_atime;
        time_t                  i_mtime;
        time_t                  i_ctime;
        unsigned long           i_blksize;
        unsigned long           i_blocks;
        unsigned long           i_version;
        struct semaphore        i_sem;
        struct semaphore        i_zombie;
        struct inode_operations *i_op;
        struct file_operations  *i_fop; /* former ->i_op->default_file_ops */
        struct super_block      *i_sb;
        wait_queue_head_t       i_wait;
        struct file_lock        *i_flock;
        struct address_space    *i_mapping;
        struct address_space    i_data;
        struct address_space    i_data;
        struct dquot            *i_dquot[MAXQUOTAS];
        struct pipe_inode_info  *i_pipe;
        struct block_device     *i_bdev;

        unsigned long           i_state;

        unsigned int            i_flags;
        unsigned char           i_sock;

        atomic_t                i_writecount;
        unsigned int            i_attr_flags;
        __u32                   i_generation;
        union {
                struct minix_inode_info         minix_i;
                struct ext2_inode_info          ext2_i;
                struct hpfs_inode_info          hpfs_i;
                struct ntfs_inode_info          ntfs_i;
                struct msdos_inode_info         msdos_i;
                struct umsdos_inode_info        umsdos_i;
                struct iso_inode_info           isofs_i;
                struct nfs_inode_info           nfs_i;
                struct sysv_inode_info          sysv_i;
                struct affs_inode_info          affs_i;
                struct ufs_inode_info           ufs_i;
                struct efs_inode_info           efs_i;
                struct romfs_inode_info         romfs_i;
                struct coda_inode_info          coda_i;
                struct smb_inode_info           smbfs_i;
                struct hfs_inode_info           hfs_i;
                struct adfs_inode_info          adfs_i;
                struct qnx4_inode_info          qnx4_i;
                struct bfs_inode_info           bfs_i;
                struct udf_inode_info           udf_i;
                struct ncp_inode_info           ncpfs_i;
                struct ncp_inode_info           ncpfs_i;
                struct proc_inode_info          proc_i;
                struct socket                   socket_i;
                struct usbdev_inode_info        usbdev_i;
                void                            *generic_ip;
        } u;
};


-- Dale.

Re: [linux-lvm] Re: IBM to release LVM Technology to the Linux

[Andi Kleen]

On Tue, Jun 27, 2000 at 11:18:16AM +1200, Dale Kemp wrote:
> Looking at the Linux VFS (Virtual FileSystem) seems to show up some problems,
> for example I was more than surprised to find a big union with all the inode types
> from every kind of filesystem in Linux. And yet there is still a call to register a
> filesystem
> with VFS. VFS is certainly not abstract. Any good OO programmer would have never
> done it this way. Maybe we need SGIs Irix/vfs system more than we
> need their XVM. See the white paper at SGI - "Porting the SGI XFS
> File System to Linux", for more on this.
> Linux VFS should know nothing about other filesystems until its told about them,
> for example when you insert a filesystem module into the kernel.
> [ Sorry this is a bit off topic for this list, but I feel its still important
> to the overall linux filesystem itself. ]

The generic VFS code just never looks into the union,it is certainly 
abstractly used. Putting it into the union is just an performance optimization 
to make it use one allocation less in critical paths. File systems that
do not want to change the source files are free to use the generic_ip
pointer instead and let it point to a private structure.

-Andi (who prefers Linux VFS over ``8.3 macro hell'' Sun/BSD derived VFS)  

Re: [linux-lvm] Re: IBM to release LVM Technology to the Linux

[Dale Kemp]

> The generic VFS code just never looks into the union,it is certainly
> abstractly used. Putting it into the union is just an performance optimization
> to make it use one allocation less in critical paths. File systems that
> do not want to change the source files are free to use the generic_ip
> pointer instead and let it point to a private structure.
>
> -Andi (who prefers Linux VFS over ``8.3 macro hell'' Sun/BSD derived VFS)

Yes, I see its abstractly used I guess OO programmers don't like the
whole concept of the union data structure, but for kernel programming,
device drivers etc it can make things go a bit quicker, and save space.

I hear from Andreas that design work is currently going on for VFS for
kernels 2.5/2.6. That's one of those things about Linux if it doesn't
exist, or needs improving, it's probably already being worked on -
relentless improvement.

-- Dale.

Re: [linux-lvm] Re: IBM to release LVM Technology to the Linux

[Andreas Dilger]

Dale writes:
> Looking at the Linux VFS (Virtual FileSystem) seems to show up some
> problems, for example I was more than surprised to find a big union
> with all the inode types from every kind of filesystem in Linux.
> And yet there is still a call to register a filesystem with VFS.
> Linux VFS should know nothing about other filesystems until its told
> about them, for example when you insert a filesystem module into the kernel.

This is a well-known issue with non-kernel linux filesystem development,
but it is not really fatal if your filesystem doesn't need a huge amount
of fs-specific data.  As long as your fs-specific data is smaller than
the largest fs-specific data (ext2), you can simply use the "generic"
pointer and overload it with your own data struct.

It was done this way originally so that inodes would be a fixed size
(so they can be re-used between filesystems) without requiring an
extra malloc for each inode, and not require an extra memory reference.
However, it would be just as easy these days to have the fs-specific
data in a slab cache and have only an pointer in the inode itself.
This would actually make some of the stacked filesystems I work with
much simpler, since you could simply keep a pointer to the underlying
fs inode data struct in your own inode data struct.

See also the current thread "Re: VFS not completely factored, and more"
in the linux-fsdevel mailing list for ideas on how to change this for 2.5.
Not only does it make the VFS more abstract, it also improves kernel
compilation because any change to ext2_fs.h will no longer cause the
recompilation of every file which includes fs.h directly or indirectly
(which seems like 50% of the kernel).

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: [linux-lvm] Re: IBM to release LVM Technology to the Linux

[benr]

Martin,

>I am advocating:
>
>1. Using existing partitioning schemes to encapsulate logical disks.
>
>   This is only relevant in the migration case and if people want to
>   test LVMS on a few disks that are already partitioned.  If your
>   system has hundreds of disks connected, you'll use a 1:1 physical
>   to logical disk mapping anyway.

What you wish to do here can be done within the LVMS Architecture.
Basically, it would require the creation of a Device Manager plug-in which
would report each partition on a device as a logical disk.  Once this is
done, all of the other LVMS Partition Management and Feature plug-ins could
be applied to the logical disk.


>2. Avoid using existing partitioning schemes to encapsulate logical
>   partitions/extents.

This could be accomplished in the LVMS Architecture by creating a Partition
Manager plug-in which implements whatever scheme you desire.  Furthermore,
it could co-exist with other Partition Manager plug-ins.  The only
constraint is that a logical disk can not be shared between multiple
Partition Manager plug-ins.

I believe that what you advocate could be implemented within the LVMS
Architecture.   Since it is not an exact match for the model underlying the
architecture, it would not be a perfect fit, but it wouldn't be a bad fit
either.  Thoughts?

Regards,

Ben

Re: [linux-lvm] Re: IBM to release LVM Technology to the Linux

[benr]

Paul,

Welcome to the discussion!

>would it not perhaps be more efficient and more purposeful if rather
>than releasing IBM specific code which will not 'drop-in' to linux,
>IBM were instead to use their knowledge gained from IBM LVM to assist
>with improving the current Linux LVM?

If the existing LVM could accommodate what our customers have asked for,
then, yes, it would have been more efficient to improve the current Linux
LVM.  However, in order for the current LVM to be able to do what our
customers have asked for, it would have to be based upon a different
architecture.  This would require major changes to the code, the equivalent
of a re-write.  This does not mean, however, that the current LVM is in any
way bad.  It just means that our customers have needs that are not being
met by the current LVM, and something different is required to meet those
needs.

Regards,

Ben

Re: [linux-lvm] Re: IBM to release LVM Technology to the Linux

[Paul Jakma]

On Mon, 26 Jun 2000 benr@us.ibm.com wrote:

> If the existing LVM could accommodate what our customers have
> asked for, then, yes, it would have been more efficient to
> improve the current Linux LVM.  However, in order for the current
> LVM to be able to do what our customers have asked for,

what have your customers asked for exactly? 

and are these customers AIX customers?

> it would have to be based upon a different architecture.  This
> would require major changes to the code, the equivalent of a
> re-write.  This does not mean, however, that the current LVM is
> in any way bad.  It just means that our customers have needs that
> are not being met by the current LVM, and something different is
> required to meet those needs.

but rather than throwing your LVM at Linux (and having 2 different
LVM implementations - bad), why not re-examine your customers needs
and work with current LVM using your experience/concepts from IBM LVM
to develop an architecture that does meet those needs. An
architecture perhaps different from current-LVM/IBM-LVM but still
drawing on that experience.

i take it adapting IBM's LVM to linux will not be straight forward,
so the choices are:

1. port IBM LVM -> 2 seperate LVM implementations.
2. use current LVM with only slight improvements (possibly not
meeting your customer's needs)
3. work with Heinz and the rest of the linux community to build a new
LVM architecture, taking the best concepts from both IBM and Heinz
LVM to build a new LVM architecture superior to all the rest.

whatever you do, i think option 1. is the least desirable.

> 
> Regards,
> 
> Ben


regards,
-- 
Paul Jakma	paul@clubi.ie
PGP5 key: http://www.clubi.ie/jakma/publickey.txt
-------------------------------------------
Fortune:
According to the latest official figures, 43% of all statistics are
totally worthless.

Re: [linux-lvm] Re: IBM to release LVM Technology to the Linux

[benr]

Hello Paul!

>what have your customers asked for exactly?

>and are these customers AIX customers?

Here are some of the things that our customers have asked for:

The ability to read, write, and manipulate AIX volume groups and logical
volumes

The ability to read, write, and manipulate OS/2 logical volumes

The ability to read, write, and manipulate NT logical volumes (have not yet
started to research this one!)

The elimination of reboots after partitioning or volume changes

All disk utilities should be volume/volume group aware, as appropriate

Elimination of data security holes ( This involves the automation of error
prone tasks which could result in the loss of data.  An example would be
the shrinking of a volume.  This involves manual steps at the moment -
specifically - the filesystem must be resized before the volume is shrunk.
If the user forgets to do this, or if the user shrinks the filesystem by
too little or the volume by too much, data loss can occur.  Another example
of a data security hole would be if fdisk and its variants are not volume
group aware, in which case a user could accidentally delete a partition
belonging to a volume group, thereby causing data loss.  Another example of
a data security hole would be if partition identifiers can change due to
disk partitioning activity - ex. hda9 becomes hda8 after deleting hda7.
This could result in the user performing an operation on the wrong
partition.  Another example of a data security hole would be if the
partitions belonging to a volume group are still visible and available for
mounting - ex. hda5, hdb7, and hdc2 are all in a volume group, yet each is
visible apart from the volume group and each can be mounted independently
from the volume group to which they belong.  There are others, but I think
you get the idea.  Corporate users are very paranoid about losing their
"mission critical data".  They want a system which allows them to do
incredibly powerful things, but which also makes it extremely hard to
"screw up".)

Usability enhancements (The users complain about there being too many
commands required to manage volumes and disks, that managing volumes and
disks is too complex.  They want a single point for controlling everything
concerning disks, partitions, volumes, etc.  They also want a simpler
storage model that is easier to understand.  It appears that volume groups
confuse most users who are not UNIX savvy, as well as a surprising number
of those who are. )


>> it would have to be based upon a different architecture.  This
>> would require major changes to the code, the equivalent of a
>> re-write.  This does not mean, however, that the current LVM is
>> in any way bad.  It just means that our customers have needs that
>> are not being met by the current LVM, and something different is
>> required to meet those needs.

>but rather than throwing your LVM at Linux (and having 2 different
>LVM implementations - bad), why not re-examine your customers needs
>and work with current LVM using your experience/concepts from IBM LVM
>to develop an architecture that does meet those needs. An
>architecture perhaps different from current-LVM/IBM-LVM but still
>drawing on that experience.

I don't understand what you are trying to say here.  See the discussion
below.

>i take it adapting IBM's LVM to linux will not be straight forward,
>so the choices are:

>1. port IBM LVM -> 2 seperate LVM implementations.
>2. use current LVM with only slight improvements (possibly not
>meeting your customer's needs)
>3. work with Heinz and the rest of the linux community to build a new
>LVM architecture, taking the best concepts from both IBM and Heinz
>LVM to build a new LVM architecture superior to all the rest.

>whatever you do, i think option 1. is the least desirable.

Option 1 provides a short term solution.  It has certain benefits to IBM
and to Linux, but is probably not best for the long term.  As such, if we
end up using option 1, we would prefer to see the various LVM
implementations merge at some point in the future.  This means that, at
some point in the future, we end up at Option 3.

Option 2 is not good.  If we do this, then we may lose our customers, and
Linux misses a window of opportunity.

Option 3 is best, especially if we can start here instead of starting at
Option 1.  The LVMS Architecture that we have released is not set in
concrete, indeed, that is one of the reasons why we started this
discussion.  IBM currently has a way to support both OS/2 logical volumes
and AIX volume groups/logical volumes using this architecture, and the
solution is rather "clean".  However, we would also like to be able to
support Linux LVM volume groups/logical volumes and Monterey volume
groups/logical volumes.  The Linux and Monterey LVMs do not fit cleanly
into the LVMS Architecture as it now stands due to the fact that these LVMs
form volume groups from partitions as well as entire drives (see my
previous post about supporting AIX volume groups and logical volumes within
the LVMS Architecture).  While there are ways in which we could support
these LVMs, the methods employed are not architecturally "clean".  Thus, we
continue to look for the proper way in which to extend the LVMS
Architecture.  Of course, there is nothing that says we have to continue
the search by ourselves, or that we should be the only ones looking ...

Another thing to consider is that the LVMS Architecture is really a
framework.  It doesn't do much by itself.  The vast majority of the
functionality of an LVMS based on this architecture lies in the plug-in
modules that are loaded.  This is what allows this architecture to support
most volume group based LVMs (such as AIX) as well as most partition based
LVMs (OS/2, possibly NT - while NT doesn't appear to use volume groups,
there may be other obstacles which could prevent support for NT).  The
ultimate functionality of the architecture is limited by the number and
types of plug-ins it allows, as well as how those plug-ins are allowed to
interact.  I don't believe that this type of power and flexibility is
available in the LVMs of other operating systems (please correct me if I am
wrong!).  If we can find the right superset of the LVMS Architecture to use
for Linux, then we can take Linux from playing catch-up to being the
cutting edge leader in logical volume management!

Regards,

Ben

Re: [linux-lvm] Re: IBM to release LVM Technology to the Linux

[Ragnar Kjørstad]

On Wed, Jun 28, 2000 at 08:23:30PM -0500, benr@us.ibm.com wrote:
> Hello Paul!
> 
> >what have your customers asked for exactly?
> 
> Here are some of the things that our customers have asked for:
> 
> The ability to read, write, and manipulate AIX volume groups and logical
> volumes
> 
> The ability to read, write, and manipulate OS/2 logical volumes
> 
> The ability to read, write, and manipulate NT logical volumes (have not yet
> started to research this one!)

Can not all theese be implemented as seperate block-devices, like md and
lvm?


> The elimination of reboots after partitioning or volume changes
Even for MS-DOS partitions?
 
> Elimination of data security holes ( This involves the automation of error
> prone tasks which could result in the loss of data.  An example would be
> the shrinking of a volume.  This involves manual steps at the moment -
> specifically - the filesystem must be resized before the volume is shrunk.

Don't LVM handle the communication with the filesystem to do this
automaticly?

> If the user forgets to do this, or if the user shrinks the filesystem by
> too little or the volume by too much, data loss can occur.  Another example
> of a data security hole would be if fdisk and its variants are not volume
> group aware, in which case a user could accidentally delete a partition
> belonging to a volume group, thereby causing data loss.  Another example of
> a data security hole would be if partition identifiers can change due to
> disk partitioning activity - ex. hda9 becomes hda8 after deleting hda7.
And how can this be eliminated? In LVM this is not a problem, because
name-space is different, but how can it be solved for msdos-partitions?

> Usability enhancements (The users complain about there being too many
> commands required to manage volumes and disks, that managing volumes and
> disks is too complex.  They want a single point for controlling everything
> concerning disks, partitions, volumes, etc.  They also want a simpler
> storage model that is easier to understand.  It appears that volume groups
> confuse most users who are not UNIX savvy, as well as a surprising number
> of those who are. )

Creating easier-to-understand user interfaces is very different from
changing the architecture in the kernel.
 

Basicly, what I'm asking is if the current architecture (just stackable
block-devices) capable of all the things you want to accomplish?



-- 
Ragnar Kjorstad

RE: [linux-lvm] Re: IBM to release LVM Technology to the Linux

[Jean-Eric Cuendet]

> Another thing to consider is that the LVMS Architecture is really a
> framework.  It doesn't do much by itself.  The vast majority of the
> functionality of an LVMS based on this architecture lies in 
> the plug-in
> modules that are loaded.  This is what allows this 

Where stands the VFS layer? Behind LVMS? Or is it just a plugin for LVMS? Or
is it replaced?

Bye
-jec

Re: [linux-lvm] Re: IBM to release LVM Technology to the Linux

[Andi Kleen]

On Thu, Jun 29, 2000 at 07:32:29AM +0200, Jean-Eric Cuendet wrote:
> 
> > Another thing to consider is that the LVMS Architecture is really a
> > framework.  It doesn't do much by itself.  The vast majority of the
> > functionality of an LVMS based on this architecture lies in 
> > the plug-in
> > modules that are loaded.  This is what allows this 
> 
> Where stands the VFS layer? Behind LVMS? Or is it just a plugin for LVMS? Or
> is it replaced?

VFS is above file systems, LVM/block devices are below.

The layering is roughly like this

        System calls  / NFS server 
                   VFS
                 Filesystems          (sometimes bypassed)
             Generic Page Cache       (sometimes bypassed)  
     	     LVM / Raid / LVMS
                 elevator 
     IDE driver / HW RAID driver / SCSI drivers 



 

-Andi

Re: [linux-lvm] Re: IBM to release LVM Technology to the Linux

[benr]

Ragnar,

Welcome to the discussion!


>> The ability to read, write, and manipulate AIX volume groups and logical
>> volumes
>>
>> The ability to read, write, and manipulate OS/2 logical volumes
>>
>> The ability to read, write, and manipulate NT logical volumes (have not
yet
>> started to research this one!)

>Can not all theese be implemented as seperate block-devices, like md and
>lvm?

My understanding is that Linux has a limited ability to stack block device
drivers.  This capability is insufficient, however, to provide the above
support, both now and in the future.  What is needed is an ability to stack
drivers on a per volume basis.  That is, each volume would have the
equivalent of its own driver stack, containing only those drivers actually
used by the volume in the order in which they are actually used.  This
means that the driver stack for each volume is independent from that of
every other volume.  Thus, volumes employing the same drivers may have
those drivers in a different order in their respective driver stacks.  I
don't see that capability in Linux right now, but I may have missed
something.

Another thing missing is conflict detection and driver based control of
driver ordering in the driver stack of a volume.  This was only briefly
mentioned in the LVMS white paper, but, in a nut shell, the LVMS defines a
series of attributes which can be associated with a plug-in module.  These
attributes are set by the creator of a plug-in module.  The attributes
allow the LVMS to detect conflicts between plug-in modules, as well as
determine where in the driver stack for a volume a plug-in module
must/may/prefers to reside.

>> The elimination of reboots after partitioning or volume changes
>Even for MS-DOS partitions?

Yes.

>> Elimination of data security holes ( This involves the automation of
error
>> prone tasks which could result in the loss of data.  An example would be
>> the shrinking of a volume.  This involves manual steps at the moment -
>> specifically - the filesystem must be resized before the volume is
shrunk.
>
>Don't LVM handle the communication with the filesystem to do this
>automaticly?

From the man page for lvreduce:

"lvreduce allows you to reduce the size of a logical volume. Be careful
when reducing a logical volume's size, because data in the reduced part is
lost!!!"

If you are using ext2, then you could use e2fsadm, but if you are using
another filesystem, then what?  Even if you are using ext2, a user could
still use lvreduce directly.  Thus, this is a data security hole.

>> If the user forgets to do this, or if the user shrinks the filesystem by
>> too little or the volume by too much, data loss can occur.  Another
example
>> of a data security hole would be if fdisk and its variants are not
volume
>> group aware, in which case a user could accidentally delete a partition
>> belonging to a volume group, thereby causing data loss.  Another example
of
>> a data security hole would be if partition identifiers can change due to
>> disk partitioning activity - ex. hda9 becomes hda8 after deleting hda7.
>And how can this be eliminated? In LVM this is not a problem, because
>name-space is different, but how can it be solved for msdos-partitions?

The way this is solved in other operating systems is that the operating
system only recognizes volumes.  Volumes are given user defined, unique
names.  Volumes are then mounted by referring to the volume's name.
Partitions are not visible to the operating system, they are only visible
to the LVMS.  If the user wishes to mount a partition, they must first make
it a volume using the LVMS.  This places the partition into the LVMS name
space and forces the user to give it a unique name.  If partitions are
created or destroyed (which must be done through the LVMS), no reboots are
required as the names of the existing volumes are not affected.  Similarly,
if a volume is created or destroyed, no reboot is required as the names of
the remaining volumes have not changed, and their associations still hold.
Of course, there are other simpler ways to handle this specific point, but
the method outlined here solves more than just the reboot problem, it
closes other data security holes as well.

One last point here is that a partition can be turned into a volume without
affecting its contents, and without affecting the ability of MS-DOS and
Windows to recognize or use it.  This is actually done by both OS/2 and NT.

>> Usability enhancements (The users complain about there being too many
>> commands required to manage volumes and disks, that managing volumes and
>> disks is too complex.  They want a single point for controlling
everything
>> concerning disks, partitions, volumes, etc.  They also want a simpler
>> storage model that is easier to understand.  It appears that volume
groups
>> confuse most users who are not UNIX savvy, as well as a surprising
number
>> of those who are. )
>
>Creating easier-to-understand user interfaces is very different from
>changing the architecture in the kernel.

Yes and no.  There are some issues which can be dealt with in the user
interface, and there are other issues which need to be dealt with
elsewhere.  As an example, consider that the users want a simple storage
model.  If the kernel supports the more complex model that the users don't
like, it would be very difficult to hide that behind a user interface.  The
code for such a user interface would tend to be complex, and complex code
is typically buggy.  Thus, a kernel change may be more appropriate in this
case.

>Basicly, what I'm asking is if the current architecture (just stackable
>block-devices) capable of all the things you want to accomplish?

No.  If it was, IBM would be working on the stackable block-devices
required to meet the needs of our customers as this would have been the
fastest and most effective path to take.  This does not mean that the
existing LVM is in any way "bad" or "inferior".  The designers of the
current LVM were trying to solve a certain set of problems, which they did.
We are trying to solve a different set of problems.  While there are many
similarities between the problem sets, there are also many significant
differences.  It is these differences that are driving us towards a
different solution.

Regards,

Ben

Re: [linux-lvm] Re: IBM to release LVM Technology to the Linux

[Dale Kemp]

>
> "lvreduce allows you to reduce the size of a logical volume. Be careful
> when reducing a logical volume's size, because data in the reduced part is
> lost!!!"
>
> If you are using ext2, then you could use e2fsadm, but if you are using
> another filesystem, then what?  Even if you are using ext2, a user could
> still use lvreduce directly.  Thus, this is a data security hole.

This is more than a problem with LVM but with device and file system
integration. Even with LVMS the problems not fully solved, maybe only
with JFS but what about ext2, ext3, reiserfs etc. I propose that the list
put some thought into this whole integration process, I think some common
interface standard is needed. Maybe something like the resizefs that I
proposed in a previous email.

toplevel:    resizefs <partition_device | logical_volume | mountpoint>

This then calls resizefs.ext2 for example again some thought is needed with
regards to volume's and partition's. Using a common interface now for volumes
could allow the command (or something like it) to work on both LVM and LVMS.
(Maybe also the remount options, etc.)
Its become clear that the most important part is some common elements for
volumes; specifics for each volume manager can be handled in each kernel
module and toolset.
Let's do this now no latter when its all incompatible, for the user's sake.
I say to IBM and SGI please lets get some common functionality, and start
drawing up a proposal document online.

What do you all think?

Proposed common volume management:

    - The 'mount' command, and options. Such as readonly etc.
    - A resize filesystem command such as "resizefs", that knows about
partitions and
       volumes.
    - mkfs (eg. mke2fs) should work with all volume types.
    - Others to be proposed.

-- Dale.

Re: [linux-lvm] Re: IBM to release LVM Technology to the Linux

[Jan Niehusmann]

On Thu, Jun 29, 2000 at 06:39:51PM -0500, benr@us.ibm.com wrote:
> If you are using ext2, then you could use e2fsadm, but if you are using
> another filesystem, then what?  Even if you are using ext2, a user could
> still use lvreduce directly.  Thus, this is a data security hole.

We'll always have that kind of 'data security hole'. We have lvreduce, we
have mke2fs, we even have cat /dev/zero >/dev/hda. 

I think admin tools should be easily usable, and that includes safety. It
should be difficult to destroy data accidently. So, obviously, it's a bad
thing if you have to shrink the fs size first, then shrink the volume size,
and if you misstype one of the sizes you lose data.

I see two possible solutions: One is an integrated tool like e2fsadm,
generalized to know about all possible filesystems. (If you call it to
shrink a fs that it doesn't know about, it fails with a proper error
message).

The second is a check in lvreduce to ensure the fs on the partition fits into
the new volume size. The user still has to call ext2resize (or another tool)
first, and then lvreduce, but user faults are caught. 

(Of course, lvreduce will have a --i-know-this-doesnt-fit-do-it-anyway option
to allow the admin to shoot himself in the foot if he really wants to...)


I know the proposed LVMS does much more than providing data security, but I'm
just not interested in many of the features, so I don't comment on them. What
I like about LVM (and I think I share this opinion with many other people) is
the ability to change partition sizes without big data moving tasks, and
without the need to care about drive borders.
And I know about the dangers of lvreduce, it did already bite me once. :-)

Jan

Re: [linux-lvm] Re: IBM to release LVM Technology to the Linux

[Ragnar Kjørstad]

On Thu, Jun 29, 2000 at 06:39:51PM -0500, benr@us.ibm.com wrote:
> >Can not all theese be implemented as seperate block-devices, like md and
> >lvm?
> 
> My understanding is that Linux has a limited ability to stack block device
> drivers.  This capability is insufficient, however, to provide the above
> support, both now and in the future.  What is needed is an ability to stack
> drivers on a per volume basis.  That is, each volume would have the
> equivalent of its own driver stack, containing only those drivers actually
> used by the volume in the order in which they are actually used.  This
> means that the driver stack for each volume is independent from that of
> every other volume.  Thus, volumes employing the same drivers may have
> those drivers in a different order in their respective driver stacks.  I
> don't see that capability in Linux right now, but I may have missed
> something.

Is it not possible to make an LVM-volume on an md device, and an md
device on an LVM-volume? That's what you want, right?

> Another thing missing is conflict detection and driver based control of
> driver ordering in the driver stack of a volume.  This was only briefly
> mentioned in the LVMS white paper, but, in a nut shell, the LVMS defines a
> series of attributes which can be associated with a plug-in module.  These
> attributes are set by the creator of a plug-in module.  The attributes
> allow the LVMS to detect conflicts between plug-in modules, as well as
> determine where in the driver stack for a volume a plug-in module
> must/may/prefers to reside.

This may be implemented within the current architecture by having the
block-device drivers export some data (e.g. in proc), and have the
userspace utilities check that data before they perform any actions.

The data in proc should be standarized, so the userspace-utilities
don't have to know every block-device specificly.

> >> The elimination of reboots after partitioning or volume changes
> >Even for MS-DOS partitions?
> 
> Yes.

There was a suggestion on L-K (or maybe it was reiserfs) that the kernel
should reread the partition-table, and compare it to the old one - if
none of the mounted partitions changed the new partition-table would be
accepted (and reboot avoided). 

> >From the man page for lvreduce:
> 
> "lvreduce allows you to reduce the size of a logical volume. Be careful
> when reducing a logical volume's size, because data in the reduced part is
> lost!!!"
> 
> If you are using ext2, then you could use e2fsadm, but if you are using
> another filesystem, then what?  Even if you are using ext2, a user could
> still use lvreduce directly.  Thus, this is a data security hole.

There are also utilities for resizing reiserfs - I believe they
communicate with LVM to do this automaticly? Is the manpage outdated, or
am I wrong here? 

The reason this don't work for other filesystems is of course that they
can't be resized at all.

> >And how can this be eliminated? In LVM this is not a problem, because
> >name-space is different, but how can it be solved for msdos-partitions?
> 
> The way this is solved in other operating systems is that the operating
> system only recognizes volumes.  Volumes are given user defined, unique
> names.  Volumes are then mounted by referring to the volume's name.

The best way to handle this (IMHO) is to provide special utilities that
ease the mounting, and do the checking. The operating-system shouldn't
prevent mounting of the partitions directly, because it is sometimes
desired.

> Partitions are not visible to the operating system, they are only visible
> to the LVMS.  If the user wishes to mount a partition, they must first make
> it a volume using the LVMS.  This places the partition into the LVMS name
> space and forces the user to give it a unique name.  If partitions are
> created or destroyed (which must be done through the LVMS), no reboots are
> required as the names of the existing volumes are not affected.  Similarly,
> if a volume is created or destroyed, no reboot is required as the names of
> the remaining volumes have not changed, and their associations still hold.

I don't like to "force" anything.... What's the problem with just
modifying the utilities to check this - or give warnings?

> One last point here is that a partition can be turned into a volume without
> affecting its contents, and without affecting the ability of MS-DOS and
> Windows to recognize or use it.  This is actually done by both OS/2 and NT.

You still need to store some metadata, right? So where can you store it
without affecting its contents? 

> >Creating easier-to-understand user interfaces is very different from
> >changing the architecture in the kernel.
> 
> Yes and no.  There are some issues which can be dealt with in the user
> interface, and there are other issues which need to be dealt with
> elsewhere.  As an example, consider that the users want a simple storage
> model.  If the kernel supports the more complex model that the users don't
> like, it would be very difficult to hide that behind a user interface.  The
> code for such a user interface would tend to be complex, and complex code
> is typically buggy.  Thus, a kernel change may be more appropriate in this
> case.

I disagree with this. The "not allow mounting partitions" issue for
instance, can easily be handled in user interfaces with _no_ complexity.

However, I'm sure some changes are needed in kernelspace to accomplish
some of the other features outlined in the paper. 



-- 
Ragnar Kjorstad

Re: [linux-lvm] Re: IBM to release LVM Technology to the Linux

[benr]

Dale,

>>
>> "lvreduce allows you to reduce the size of a logical volume. Be careful
>> when reducing a logical volume's size, because data in the reduced part
is
>> lost!!!"
>>
>> If you are using ext2, then you could use e2fsadm, but if you are using
>> another filesystem, then what?  Even if you are using ext2, a user could
>> still use lvreduce directly.  Thus, this is a data security hole.
>
>This is more than a problem with LVM but with device and file system
>integration.

Yes.

> Even with LVMS the problems not fully solved, maybe only
>with JFS but what about ext2, ext3, reiserfs etc.

The LVMS solves this problem through Filesystem Interface Modules (FIM).
Refer to page 11 of the white paper, under the "Filesystem Participation"
section.  Thus, all that is needed to make ext2, ext3, reiserfs, JFS, XFS,
HPFS, FAT, etc. work with the LVMS is an appropriate FIM.  How hard is it
to write a FIM?  That depends upon how hard it is to resize the filesystem
that the FIM is being written for, not much else.  Just because a
filesystem does not have a FIM, though, does not mean that that filesystem
can not be used with the LVMS.  It just means that the LVMS will not be
able to perform certain operations on volumes which employ that filesystem.

>I propose that the list
>put some thought into this whole integration process, I think some common
>interface standard is needed. Maybe something like the resizefs that I
>proposed in a previous email.
>
>toplevel:    resizefs <partition_device | logical_volume | mountpoint>
>
>This then calls resizefs.ext2 for example again some thought is needed
with
>regards to volume's and partition's. Using a common interface now for
volumes
>could allow the command (or something like it) to work on both LVM and
LVMS.
>(Maybe also the remount options, etc.)
>Its become clear that the most important part is some common elements for
>volumes; specifics for each volume manager can be handled in each kernel
>module and toolset.
>Let's do this now no latter when its all incompatible, for the user's
sake.
>I say to IBM and SGI please lets get some common functionality, and start
>drawing up a proposal document online.
>
>What do you all think?
>
>Proposed common volume management:
>
>    - The 'mount' command, and options. Such as readonly etc.
>    - A resize filesystem command such as "resizefs", that knows about
>partitions and
>       volumes.
>    - mkfs (eg. mke2fs) should work with all volume types.
>    - Others to be proposed.

The LVMS already does what you are talking about, and it does so without
imposing any particular user interface.  By having the integration occur in
the LVMS instead of in the user interface, the user interface is easier to
write, and data security holes can be controlled and/or eliminated.
Furthermore, the LVMS was designed to accommodate multiple user interfaces,
and having the integration occur in the LVMS eliminates the duplication of
code and effort which would be required if the user interfaces had to
implement the integration.

Regards,

Ben

Re: [linux-lvm] Re: IBM to release LVM Technology to the Linux

[Dale Kemp]

Ben,

I'm beginning to wonder why IBM is even on this list every suggestion is for
a pure LVMS solution. You say you care about LMS but everything shows that
IBM only wants there LVMS solution. I understand that LVMS has extra
functionality, I suspect it has many more years of development put into it
than LMS. I also think its a great idea for IBM to port, since its good for
your
existing users and maybe new ones too. The point I'm trying to make is why
not have some common standard here, even my proposal you answered,
"The LVMS already does what you are talking about ... integration occurs in
the LVMS instead of in the user interface, ...". Again that's not the point,
this
is a one eyed view once again. lvms, lvms, lvms... You suggest solutions and
they are "LVMS does this, LVMS does that".
Maybe IBM still doesn't get the working with the community idea here,
people on this list have been very open minded regards LVMS and generally
understand what you are trying to do, and are happy about LVMS coming to
Linux. But most of the list wants you to help expand Linux and understand
that they want you to help with it overall. Maybe some of that LVMS interface
could be used in LMS, or atleast give Linux a standard concept of a volume
.vs. a partition, even if all the insides of each piece are completely
different.
See if you can answer without saying LVMS does this... And we can tell users
in the future "integration occurs in the LVMS instead of the user interface".

-- Dale.

Re: [linux-lvm] Re: IBM to release LVM Technology to the Linux

[Jens Benecke]

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

Hi,

this is going to be a tad longer. I have read this discussion for some time
now and I thought I'd just throw in some of my thoughts.


On Sat, Jul 01, 2000 at 09:30:01AM +1200, Dale Kemp wrote:
 
> I'm beginning to wonder why IBM is even on this list every suggestion is
> for a pure LVMS solution. You say you care about LMS but everything shows
> that IBM only wants there LVMS solution. I understand that LVMS has extra
> functionality, I suspect it has many more years of development put into

I think the reason why IBMs developers always point to their solution is
partly

	* because they know their solution works and has certain features,
	  and they do NOT (yet) know about LVM/md/...

	* because they have a (complete?) platform-independant API that
	  works with their current machines, and they see that it works,
	  and they want to introduce it to Linux,

	* because they have customers that rely on them and their LVMS, and
	  have neither nerves nor chances nor time to do any kind of
	  experimentation. It would therefore be much easier for IBM just
	  to port and clean up their LVMS than to integrate it with current
	  implementations.  They do offer the merge though.


I for one find it somewhat flattering that IBM donates the result of years
of development into the gigantic mind share pool that created Linux.  The
big boys are beginning to understand how the free software principle works:
You can harvest all you want, but you will benefit most if you donate
yourself.

At the same time, though, IBM needs to understand that even in the free
software community, development is partly politics, and there are several
reasons why the IBM LVMS will problably not be accepted into the kernel, no
matter how good it is:


	* There is already a LVM that does "most of the important things".
	  Of course, "important" is stretchable into infinity, but remember
	  that most developers don't have multibillion dollar customers
	  that need <special_feature> or have terabytes of storage. So they
	  develop something that fits the needs of most people. Linux-LVM
	  does this "well enough" (again, stretchable).

	* Some people seem to be afraid that we are falling into some kind
	  of dependance upon IBM when we accept their LVMS. This is a
	  perfectly legitimate claim UP TO AND UNTIL IBM starts releasing
	  complete compilable code, and does it under GPL or BSD licence.
	  They have promised to do so, they haven't DONE anything to that
	  effect already (or have I missed something?).

	* It is completely understandable that now that IBM has entered the
	  game, developers feel "overrun". They have devoted energy to
	  their own LVM implementation and now comes the "big guy" and
	  builds a big stone castle around their cosy cottage. (just a
	  comparison) 
	  
	  Of course, being "swallowed" this way works up emotions. We must
	  find an agreement (e.g. the cottage takes care of providing food
	  and meals to all the castle inhabitants. :)


> Maybe IBM still doesn't get the working with the community idea here,

I think they do, but only partly. Developers tend to be more easily
convinced by working code, than by arguments. If IBM releases their code
(GPL'ed, of course) and it is really easy to write plug-ins and there is
good documentation, and it is cross-platform and so on, it will most
probably be adopted. 

If they want the Linux community to accept it before they get the code out,
however, IBM will probably have a hard time.

Just for comparison: "Easy code" is partly why the KDE project exploded so
quickly out of nowhere - they found a library (Qt) which was well
documented and stable, and really easy (you could program a text editor in
20 lines of code) -- and it was FUN. 

Programming must be FUN. That is one of the most important things in the
free software community. And it is not at all childish: If you do something
for free, you'll want to enjoy doing it.

> See if you can answer without saying LVMS does this... And we can tell
> users in the future "integration occurs in the LVMS instead of the user
> interface".

This could be hard, because they do have a working solution (at least, on
other OS). But, until they actually release code, we cannot really argue
what will integrate into what.

So, IBM, please release the code and let the hackers digest it. Then, we
can really determine if your LVMS is worth converting Linux-LVM into
plug-in modules (or vice versa). From what you told us, it is. 

But without code, who knows?


-- 
"The PROPER way to handle HTML postings is to cancel the article, then hire
a killer to kill the poster, his wife and kids, and fuck his dog and smash
his computer into little bits. Anything more is just extremism." - ptomblin

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

Re: [linux-lvm] Re: IBM to release LVM Technology to the Linux

[benr]

Ragnar,


>Is it not possible to make an LVM-volume on an md device, and an md
>device on an LVM-volume? That's what you want, right?

If both volumes could exist and be used simultaneously, then this would be
a simple example of what we want.  However, I have been told that:

"What is definitely lacking is a generic API for this case; the current way
of letting remappers change a function pointer requires special support in
every single remapper and it is hard to remove or insert them on the fly;"
(Andi Kleen - from a post earlier this month on this thread)

This tells me that the current mechanism can not handle what we desire.

>This may be implemented within the current architecture by having the
>block-device drivers export some data (e.g. in proc), and have the
>userspace utilities check that data before they perform any actions.

>The data in proc should be standarized, so the userspace-utilities
>don't have to know every block-device specificly.

What you suggest could be made to work, but the way it is handled by the
LVMS is cleaner and more efficient, and requires much less code.

>> >> The elimination of reboots after partitioning or volume changes
>> >Even for MS-DOS partitions?
>>
>> Yes.
>
>There was a suggestion on L-K (or maybe it was reiserfs) that the kernel
>should reread the partition-table, and compare it to the old one - if
>none of the mounted partitions changed the new partition-table would be
>accepted (and reboot avoided).

What constitutes a change to a mounted partition?  Currently, the creation
of a new partition (or the deletion of an existing one) can cause the
identifiers associated with existing partitions to change, even though the
existing partitions have not been changed themselves.  Thus, unless this is
changed, the proposed method does not eliminate reboots due to partitioning
changes.

>> >From the man page for lvreduce:
>>
>> "lvreduce allows you to reduce the size of a logical volume. Be careful
>> when reducing a logical volume's size, because data in the reduced part
is
>> lost!!!"
>>
>> If you are using ext2, then you could use e2fsadm, but if you are using
>> another filesystem, then what?  Even if you are using ext2, a user could
>> still use lvreduce directly.  Thus, this is a data security hole.
>
>There are also utilities for resizing reiserfs - I believe they
>communicate with LVM to do this automaticly? Is the manpage outdated, or
>am I wrong here?
>
>The reason this don't work for other filesystems is of course that they
>can't be resized at all.

Other filesystems can be resized, it is just that a resize utility has not
be written for them yet! :-)

There is currently no true integration between the LVM and the filesystems.
The resize utilities that are available attempt to hide this by having the
utility communicate with both the LVM and the filesystem, but there is no
intrinsic communication between the filesystems and the LVM as there would
be in the LVMS.  As a result, lvreduce does not talk to the filesystems,
and bad things can happen!

>> >And how can this be eliminated? In LVM this is not a problem, because
>> >name-space is different, but how can it be solved for msdos-partitions?
>>
>> The way this is solved in other operating systems is that the operating
>> system only recognizes volumes.  Volumes are given user defined, unique
>> names.  Volumes are then mounted by referring to the volume's name.
>
>The best way to handle this (IMHO) is to provide special utilities that
>ease the mounting, and do the checking. The operating-system shouldn't
>prevent mounting of the partitions directly, because it is sometimes
>desired.

Special utilities - this means more commands that a user must learn - a
more complicated user interface.  Our customers are already saying that the
existing user interface it too complicated and too hard to use.  Adding
more special utilities just makes the situation worse.

What we are talking about here is making the user go through the LVM to
mount a partition.  This gives the LVM the opportunity to examine what the
user is doing and ensure that it does not violate the integrity of any
volumes/volume groups.  This in no way prevents the user from mounting a
partition, it just allows the LVM to be involved.  It also gives the user a
single place to go to manipulate his volumes/volume
groups/partitions/disks.

>> Partitions are not visible to the operating system, they are only
visible
>> to the LVMS.  If the user wishes to mount a partition, they must first
make
>> it a volume using the LVMS.  This places the partition into the LVMS
name
>> space and forces the user to give it a unique name.  If partitions are
>> created or destroyed (which must be done through the LVMS), no reboots
are
>> required as the names of the existing volumes are not affected.
Similarly,
>> if a volume is created or destroyed, no reboot is required as the names
of
>> the remaining volumes have not changed, and their associations still
hold.
>
>I don't like to "force" anything.... What's the problem with just
>modifying the utilities to check this - or give warnings?

1.  Every utility would have to contain the appropriate set of checks.  If
you miss a check in a utility, then you have a data security hole.  It is
easier to have all of the checks in one place - the LVM.

2.  The method you outlined before does not eliminate reboots.  You need a
major change to the way partitions are identified and accessed in order to
eliminate reboots.  If you go to the method used by other operating
systems, you kill several birds with one stone.  Otherwise, to eliminate
reboots, you need to devise a new method for identifying and communicating
with partitions that avoids the problems of the current one.

>> One last point here is that a partition can be turned into a volume
without
>> affecting its contents, and without affecting the ability of MS-DOS and
>> Windows to recognize or use it.  This is actually done by both OS/2 and
NT.
>
>You still need to store some metadata, right? So where can you store it
>without affecting its contents?

There is a minimal amount of metadata required to do this.  This data can
be stored in either a centralized or distributed fashion.  In the
centralized approach, the metadata is stored in a database to which only
the LVM has both read and write access.  In the distributed method, the
metadata is stored on the disk itself.  Where it is stored depends upon the
partitioning scheme in use on the drive.  As an example, a partition could
be set aside for the use of the LVM.  In this partition, the LVM could
store whatever it wanted, including the metadata to turn a partition into a
volume.  Another method would be to store the metadata in an unused area of
the disk.  This method is actually used by OS/2 since the partitioning
scheme used by MS-DOS/Windows/OS2 always results in some unused sectors.
There are probably other methods as well.

Regards,

Ben

Re: [linux-lvm] Re: IBM to release LVM Technology to the Linux

[Ragnar Kjørstad]

On Fri, Jun 30, 2000 at 03:28:04PM -0500, benr@us.ibm.com wrote:
> >Is it not possible to make an LVM-volume on an md device, and an md
> >device on an LVM-volume? That's what you want, right?
> 
> If both volumes could exist and be used simultaneously, then this would be
> a simple example of what we want.  However, I have been told that:
> 
> "What is definitely lacking is a generic API for this case; the current way
> of letting remappers change a function pointer requires special support in
> every single remapper and it is hard to remove or insert them on the fly;"
> (Andi Kleen - from a post earlier this month on this thread)

adding and removing remappers on the fly? How is that supposed to work?
How do you add raid5 on the fly?

I don't know anything about what is needed in the remappers, and which
remappers support this and not - maybe someone more familiar with md and
lvm care to comment?

> >> >> The elimination of reboots after partitioning or volume changes
> >> >Even for MS-DOS partitions?
> >>
> >> Yes.
> >
> >There was a suggestion on L-K (or maybe it was reiserfs) that the kernel
> >should reread the partition-table, and compare it to the old one - if
> >none of the mounted partitions changed the new partition-table would be
> >accepted (and reboot avoided).
> 
> What constitutes a change to a mounted partition?  Currently, the creation
> of a new partition (or the deletion of an existing one) can cause the
> identifiers associated with existing partitions to change, even though the
> existing partitions have not been changed themselves.  Thus, unless this is
> changed, the proposed method does not eliminate reboots due to partitioning
> changes.

Yes, the suggestion didn't aim at eliminate all reboots, but it would
eliminate need for reboot when just changing the partitions at the end
of your disk.

I see two possibilities for solving the problem with changing
identifiers:
* Change the data saved about stored partitions, to reflect the new
  partition-names (and minor numbers)
* Make the minor-numbers act dynamicly - so that they never change.
  I supposed the "labels" in the partition-table can be used
  to create names that don't depenod on minor-numbers.

> >There are also utilities for resizing reiserfs - I believe they
> >communicate with LVM to do this automaticly? Is the manpage outdated, or
> >am I wrong here?
> >
> >The reason this don't work for other filesystems is of course that they
> >can't be resized at all.
> 
> Other filesystems can be resized, it is just that a resize utility has not
> be written for them yet! :-)
And once they are written, LVM will be able to use them, right?

> There is currently no true integration between the LVM and the filesystems.
> The resize utilities that are available attempt to hide this by having the
> utility communicate with both the LVM and the filesystem, but there is no
> intrinsic communication between the filesystems and the LVM as there would
> be in the LVMS.  As a result, lvreduce does not talk to the filesystems,
> and bad things can happen!

Why do bad things happed just because of this? Having the userspace
utilities change sizes of both filesystem and volume makes much sence to
me. Of course, resize-utilities have to have standardized names and
command-line options, just like mkfs. (like someone proposed in another
mail).

> >The best way to handle this (IMHO) is to provide special utilities that
> >ease the mounting, and do the checking. The operating-system shouldn't
> >prevent mounting of the partitions directly, because it is sometimes
> >desired.
> 
> Special utilities - this means more commands that a user must learn - a
> more complicated user interface.  Our customers are already saying that the
> existing user interface it too complicated and too hard to use.  Adding
> more special utilities just makes the situation worse.

No, you can write a utility that handles partitioning, creating
md-devices, setting up LVM-modules and manipulating filesystems on them.
If you really want to prevent your users to do stupid stuff, you can
even remove the regular programs (fdisk, mount, mkfs and so on) from
your installation.

> >I don't like to "force" anything.... What's the problem with just
> >modifying the utilities to check this - or give warnings?
> 
> 1.  Every utility would have to contain the appropriate set of checks.  If
> you miss a check in a utility, then you have a data security hole.  It is
> easier to have all of the checks in one place - the LVM.

It should be handled in a userspace library that knows how to
communicate with the different blockdevices and filesystems. Policy
don't belong to kernel-space.
 
> 2.  The method you outlined before does not eliminate reboots.  You need a
> major change to the way partitions are identified and accessed in order to
> eliminate reboots.  If you go to the method used by other operating
> systems, you kill several birds with one stone.  Otherwise, to eliminate
> reboots, you need to devise a new method for identifying and communicating
> with partitions that avoids the problems of the current one.

Well, I'm all for a way to be able to change partitions on the fly. But
unless it's backward compatible (that is, still accessible to all
operating-systems, and not having to make it's own partition for
metadata or anything like that), I can just use LVM.

> >You still need to store some metadata, right? So where can you store it
> >without affecting its contents?
> 
> There is a minimal amount of metadata required to do this.  This data can
> be stored in either a centralized or distributed fashion.  In the
> centralized approach, the metadata is stored in a database to which only
> the LVM has both read and write access.  In the distributed method, the
> metadata is stored on the disk itself.  Where it is stored depends upon the
> partitioning scheme in use on the drive.  As an example, a partition could
> be set aside for the use of the LVM.  In this partition, the LVM could
> store whatever it wanted, including the metadata to turn a partition into a
> volume.  Another method would be to store the metadata in an unused area of
> the disk.  This method is actually used by OS/2 since the partitioning
> scheme used by MS-DOS/Windows/OS2 always results in some unused sectors.
> There are probably other methods as well.

So how do you start using your LVM with an existing full disk? 


-- 
Ragnar Kjorstad

Re: [linux-lvm] Re: IBM to release LVM Technology to the Linux

[benr]

Jan,

Welcome to the discussion!


>On Thu, Jun 29, 2000 at 06:39:51PM -0500, benr@us.ibm.com wrote:
>> If you are using ext2, then you could use e2fsadm, but if you are using
>> another filesystem, then what?  Even if you are using ext2, a user could
>> still use lvreduce directly.  Thus, this is a data security hole.
>
>We'll always have that kind of 'data security hole'. We have lvreduce, we
>have mke2fs, we even have cat /dev/zero >/dev/hda.

lvreduce doesn't need to be a data security hole.  In the LVMS, the
filesystems have direct input to the LVMS through the Filesystem Interface
Modules (FIM).  This input is gathered by the LVMS, not by the user
interface.  Thus, any user interface which issues a command to the LVMS to
resize a volume will automatically cause the affected filesystem to be
consulted.  Thus, in the LVMS, lvreduce would not be a data security hole
as the LVMS would consult with the affected filesystem.

In other words, under the LVMS, the LVMS assumes the responsibility for
consulting the affected filesystem before resizing a volume, not the user
interface.  Under the current system, the user interface is responsible for
such integration.

>
>I think admin tools should be easily usable, and that includes safety. It
>should be difficult to destroy data accidently. So, obviously, it's a bad
>thing if you have to shrink the fs size first, then shrink the volume
size,
>and if you misstype one of the sizes you lose data.

Agreed.

>
>I see two possible solutions: One is an integrated tool like e2fsadm,
>generalized to know about all possible filesystems. (If you call it to
>shrink a fs that it doesn't know about, it fails with a proper error
>message).
>
>The second is a check in lvreduce to ensure the fs on the partition fits
into
>the new volume size. The user still has to call ext2resize (or another
tool)
>first, and then lvreduce, but user faults are caught.
>
>(Of course, lvreduce will have a --i-know-this-doesnt-fit-do-it-anyway
option
>to allow the admin to shoot himself in the foot if he really wants to...)

There is a third option.  The third option is to remove the responsibility
for integration from the user interface and place it in the LVM.  This is
what the LVMS does, as the previous discussion on lvreduce showed.

Regards,

Ben