Summary:
Think about how and where (and by whom) the storage is to be managed.
What is the pattern? YES, I am beginning to see a pattern as we discuss it.


On 10/05/2015 11:23 AM, Sergey Korzhevsky wrote:
>  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?

Oh my personal systems, I use LVM for all filesystems except the boot
volume.
Once the system is up, the boot volume is out of the picture.
(I maintain the kernel and related files by copying them from /boot to
wherever they physically reside. But that's just me.)

Last time I used LVM at work, it was primarily WAS, but also included
Tomcat and/or IHS (IBM's spin on Apache) and DB2 (UDB). Backing store in
that context was primarily SAN. Note what Robert Nix said about using
ECKD for the backing store: you can grow your volume groups (VGs) by
adding physical volumes (PVs).

As Scott just noted (overlapping email) SAN volumes tend to be much
larger, but even there it's common to add a PV to a VG as the needs grow
and the LVs grow.


> 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?

Can't say that I use LVM no matter what, but for my "big storage" it is
first choice. Always.

You mention web server as an example.
Common use of web servers today is to sit between your users and your
applications. For that, you don't need "big storage". So for a web
server, I'd let VM do your volume management, doling out minidisks to
such a guest. Little value in LVM there. (This is assuming you have VM
behind the server. For anything *not* virtual, go with LVM.)

But IF you have ANY concerns that your web servers will need more file
storage, go with LVM. It won't hurt. Even without hard numbers,
experience indicates that the insertion loss with LVM is no issue.

Three strikes in favor of LVM: big storage, a guest with storage growth
needs, anything not virtual.


> 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? :)

It's not a question of adequacy or sufficiency. It's a question of
management.

I am seeing a pattern ... a need to differentiate how much you have
versus how you will manage it.

Am loving the conversation. I hope this helps.

-- 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/

Reply via email to