Hi Rick,
Could you tell me some details, because it is not obvious for what type
of services you are actually using LVM? Is this Websphere, databases,
Samba, log storage, custom application with a lot of data, anything else?
Stories about TSM and Samba are great, but this is one installation for
the site and we are speaking in terms of z/VM, right?
Maybe i need to ask additional query: do you use LVM no matter what? For
example, if you need to create one linux (maybe a bunch of them) with
webserver (it is relatively small), will you use LVM anyway?
DASD now can be 27 and 54GB, which is plenty of space for normal
application use (except DB). Is it not enough for your needs?
Maybe you initially allocate as little space as possible (say 1GB) and
then add later?
Basically, what is the pattern? :)
Thank all who will respond and already responded.
WBR, Sergey
Rick Troth <r...@casita.net>
Sent by: Linux on 390 Port <LINUX-390@VM.MARIST.EDU>
05-10-15 17:18
Please respond to Linux on 390 Port
To: LINUX-390@VM.MARIST.EDU
cc:
Subject: Re: LVM usage
Two great responses from Bob and Berry. Here's my LVM story too.
On 10/05/2015 08:56 AM, Sergey Korzhevsky wrote:
> Could you, please, explain me a real usage of the LVM
> in the server environments with z/VM or whatever.
I was introduced to LVM by colleagues.
Since then, I have used it increasingly.
It is the central facilitator for most of my storage needs.
> Do you really need to "online" expand your "opt" or "home" directory
> which is worth to have additional layer in disk access?
Online resizing works very well.
For me, there is no additional layer
because I use LVM without partitioning.
Where possible, I discard the partitioning "layer" in favor of LVM.
In other words, where it can be done, I stamp the whole disk as a PV
rather than stamping one or more partitions.
Recent discussion exposes a bug in recent LVM utilities where there is
some sad confusion between partitioned and unpartitioned physical
volumes. Other than that, LVM is everything partitioning wanted to be if
partitioning grew up.
Hard numbers exposing the insertion loss from use of LVM would be great.
Best practice recommends use of LVM for the administrative advantage.
> Moreover, databases already have such functionality
> (tablespace/containers), so they don't need LVM.
There are many places we see functional overlap. Not only databases, but
also ...
+ EVMS combined multipath support with volume management, yet LVM won
+ newer filesystems combine volume management with the FS, and LVM is
losing
There is no one size fits all, so you'll want to dig-into the
capabilities of LVM to answer your own needs. But LVM is an excellent
solution with fewer layering violations than the overlaps mentioned
here. (It fits the Unix rule of do one thing and do it well.)
-- R; <><
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
