LVM and NFS mounts

[jarod-ajLrJawYSntWk0Htik3J/w at public.gmane.org (Jarod Wilson)]

On Apr 15, 2009, at 11:13 AM, David Rosenstrauch wrote:

> Jerry Feldman wrote:
>> On 04/15/2009 08:01 AM, Stephen Goldman wrote:
>>> Hello Blu,
>>>    Looking for some discussion points on whether exporting LVM
>>> volumes as NFS mount points is recommended or not .
>>> I am interested in hearing experiences of others. OS is RHEL 5.3
>>>
>> Our whole system at work is LVM and NFS (using automount). I don't  
>> think
>> we could operate without using LVM. When we upgraded to RHEL 5.2, we
>> reorganized to set up the system physical drive as a single Physical
>> volume, and the remainder of the drives as another physical volume  
>> with
>> a number of logical volumes. FWIW, I think that LVM provides a
>> tremendous amount of flexibility with little risk.
>
> Getting off the topic of LVM+NFS a bit here, but I've heard that a  
> setup
> like that (i.e., a logical volume that spans multiple physical drives)
> can actually get you into trouble.  I can't recall the exact  
> specifics,
> but the gist was that if one of the physical drives dies or gets
> corrupted, LVM can get pretty hosed trying to serve up the data on the
> LV.  Old wives' tale?

Nope, that's true. Its often possible to recover all the data  
contained solely on the drives that haven't failed, but its not  
entirely straight-forward. Its sort of like JBOD, only slightly more  
perilous, as the other drives *do* care if a member of the group  
disappears -- especially if its data that spans more than one drive.

Personally, I'd only do multi-drive LVM atop a RAIDx for x > 0, unless  
I didn't care about the potential to lose all my data. However, note  
that at least in 32-bit kernel land, if you do software raid + lvm + a  
stack-greedy file system and/or disk driver, you have a decent chance  
at stack overflows. Not as bad as was once the case, and pretty much a  
non-issue on 64-bit kernels, but still a chance.

-- 
Jarod Wilson
jarod-ajLrJawYSntWk0Htik3J/w at public.gmane.org