On Wed, Dec 11, 2013 at 10:00 AM, Jeff Siddall <[log in to unmask]> wrote:
> On 12/10/2013 07:49 PM, Paul Robert Marino wrote:
>>
>>
>> Well in the case of migrating from one storage array to an other newer
>> bugger one the LVM migration capability is handy.
>> Any one who has had to go through the pain of a SAN migration especially
>> to a different SAN vendor will see the value of LVM there. That said
>> that only became stable enough to really trust it on critical
>> infrastructure a few years ago.
>> The ease in growing a volume on a LUN comes from the fact that LVM
>> volume group can span multiple logical disk partitions and or LUNs
>>   although again this really only became stable enough to trust it on
>> critical infrastructure a few years ago as well.
>>
>> Early on there were many problems with LVM but over the years its
>> matured significantly I've begun to trust it more  and more since the
>> release of El6, where under EL5 I absolutely refused to use it on any
>> production box.
>
>
> Yes, it has improved over time, but I wouldn't call it unusable in RHEL5.  I
> have a RHEL5 server which has been running LVM since it was installed 4
> years ago, and it is at 99.996% uptime (excluding scheduled maintenance).

On early versions of RHEL5 LVM failed several QA stress test I ran on it.
latter versions of RHEL5 with LVM did better but it was still safer to
do without it.
now in RHEL6 it seams to pass all the test.
the tests included incrementally growing volumes a few hundred times,
and repeated multiple parallel (2x#CPU cores) stress tests with dt.d
of large files.

this is how I tested
1) dt.d read write tests with keep files option.
2) grow by one GB
3) dt.d read test of the original dt.d test files
4) repeat 100 times.

When compaired to just using parted to grow the partition and rather
than LVM under RHEL 5 it always passed but would fail with LVM. the
number of times it took were different but there it was consistent in
the fact that it would eventually fail.
with RHEL 6 it always passed with LVM.

>
> Jeff