LVM and NFS mounts
Jarod Wilson
jarod-ajLrJawYSntWk0Htik3J/w at public.gmane.org
Wed Apr 15 11:28:13 EDT 2009
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
More information about the Discuss
mailing list