[linux-lvm] Best Practices deploying LVM
jockah at gmail.com
Fri Oct 30 21:03:53 UTC 2009
Well, finally my english results a barrier for explain myself (lol).
Anyway, now I have another point of view, so thank you all very much for
2009/10/30 Ray Morris <support at bettercgi.com>
> With your way, you can add a new 2GB disk and use
> half of it for /home, half for /opt, if you wish.
> You can also leave some of it unused and expand
> any LV in the future as needed. That's one important
> reason why most people use voluem groups as groups -
> contianing several volumes. Does your colleague know
> of ANY advantage to creating a bunch of different
> groups? If not, your way wins - it has advantages
> over his way, and his way has no advantage.
> we have to discard different kinds of hard disk
>> because they're exactly the same
> I have no idea what this is supposed to mean.
> Different kinds of hard disk are exactly the same?
> If this is supposed to mean "we are not able to
> use different types of drives for different
> partitions", I can understand that. However,
> for what purpose would you use different types
> of disks? Perhaps he wants a fast disk for one
> partition, and a large, cheap disk for another
> partition? If you use two cheap disks in a
> striped LV it's going to be faster AND cheaper
> than the "fast drive" option. MAYBE if you were
> going to use a super fast RAID array of SSD drives
> for some small amount of data, but not if we're
> talking standard magnetic hard drives.
> a lot of servers running under VMware. This client
>> have a lot of problems with the storage, because they
>> never have enough space so when they have to allocate
>> disk in servers, they add small virtual hard disks
>> with, for example, 5 or 10GB.
> lvextend. Ours resize automatically on the fly, using
> a cron job that checks to see if any virtual servers
> need more space.
> discarding concept things like a volume group was designed
>> to be a group, because we're looking for good reasons
> "Concept reasons", like using the tool designed for the
> job, may be the very best reasons because that one reason
> actually covers the hundred reasons that don't come to mind
> immediately. You don't know what issues you'll run into
> next week or next month, but you can bet you won't be the
> first one - other people will have had the same issues,
> and will use the standard tools for the standard purposes
> to solve that problem. Better for you if you can use
> the same solutions. Also, there are certain features
> and optimizations you don't know about, but you'll gain
> from those grouping features if you use groups as groups.
> No one knows about the features and optimizations that
> will be added next year, but if you use the tools the
> way they were designed you'll benefit from future
> enhancements that allow you to better use them for their
> Ray Morris
> support at bettercgi.com
> Strongbox - The next generation in site security:
> Throttlebox - Intelligent Bandwidth Control
> Strongbox / Throttlebox affiliate program:
> On 10/30/2009 03:52:43 AM, Abraham Pérez wrote:
>> Thanks for the instant answers!
>> Well... I'll try to explain myself better. I'm working in a client who
>> a lot of servers running under VMware. This client have a lot of problems
>> with the storage, because they never have enough space so when they have
>> allocate disk in servers, they add small virtual hard disks with, for
>> example, 5 or 10GB.
>> Then for the OS installation, we follow the basic schema based on disk
>> partitions (/dev/sda1 pointing to / with ext3, /dev/sda2 pointing to /home
>> and so on) and for the applications data, we use VG and LV pointing to
>> The client have some applications who need a lot of mountpoints, so my
>> colleague adds 1-3 LV per VG (aproximated) and I only create only one VG
>> inside it, different LVs. With this infrastructure, we have to discard
>> different kinds of hard disk because they're exactly the same... and we
>> that doubt: what schema is better and why, discarding concept things like
>> volume group was designed to be a group, because we're looking for good
>> reasons based in performance of future actions, it's not important... or
>> I mistaken???
>> I don't know if I explained myself very well, so thanks all anyway!
>> Abraham Pérez
>> 2009/10/30 <malahal at us.ibm.com>
>> > Ray Morris [support at bettercgi.com] wrote:
>> > > I don't know about a whitepaper, but I can address
>> > > your example.
>> > >
>> > > > he makes one volume group for each logical volume (more or less)
>> > >
>> > > If each one has one volume, that's not exactly a volume
>> > > GROUP, is it? If groups and volumes are basically synomous,
>> > > he gives up all the benfits of groups. In fact, he gives
>> > > up most of the benefits of logical volumes, since each PV
>> > > has to be in one group, and each VG is one LV, you're left
>> > > with one LV per PV - might as well just use partitions
>> > > directly.
>> > I agree, you lose some flexibility but it has some advantage compared to
>> > plain partitions without LVM. E.g. he can make a file system larger than
>> > any disk with multiple disks in the above LVM (one LV per VG)
>> > configuration. There are other advantages. I am not sure the reason for
>> > making only one LV per VG though!
>> > Thanks, Malahal.
>> > _______________________________________________
>> > linux-lvm mailing list
>> > linux-lvm at redhat.com
>> > https://www.redhat.com/mailman/listinfo/linux-lvm
>> > read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
> ------quoted attachment------
>> linux-lvm mailing list
>> linux-lvm at redhat.com
>> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
> linux-lvm mailing list
> linux-lvm at redhat.com
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the linux-lvm