Sponsored Content
Special Forums Hardware Filesystems, Disks and Memory Linux Storage system: looking for advices Post 302385275 by Loic Domaigne on Thursday 7th of January 2010 04:15:48 PM
Old 01-07-2010
Good Evening,

Quote:
Originally Posted by pludi
No, it's not possible with LVM alone. LVM is designed to simplify the management of multiple, different devices by grouping them together. Bonus is a slight speed improvement. If you loose one drive with LVM, the data on it is gone for good too, but it's easy to extend the size.
Since I am not very fluent in LVM, I set-up a virtual KVM/Qemu guest with Linux in order to play with LVM and investigate possible failures scenario. Enclosed the results of my experiments.

I have the following setup: a volume group containing the following physical volume /dev/vda6, /dev/vdb2 and /dev/vdb3. I have only one logical volume than spans the entire volume group. ext3 is used as filesystem.
Code:
+--------------------------------------------------+
|                    ext3                          |
+--------------------------------------------------+
+--------------------------------------------------+
|                    mylv                          | logical volume = 100%VG
+--------------------------------------------------+
+--------------------------------------------------+
|                    myvg                          | volume group = vda6, vdb2, vdb3 
+--------------------------------------------------+
+-------------+     +-------------+    +-----------+
| /dev/vda6   |     | /dev/vdb2   |    | /dev/vdb3 |
+-------------+     +------------+    +-----------+

It is possible to save the current volume group meta information using vgcfgbackup.
I failed /dev/vdb3, /dev/vdb2 and /dev/vda6 respectively (zeroed the partition using dd). For vdb2 and vdb3, I could restore the ext3 filesystem as follows:
- recreate the physical volume of the failed partition, giving the right uuid label.
- restore the volume group meta information using vgcfgrestore
- repairing the ext3 filesystem using fsck.
As expected, only the files from the failed partition were missing after the restore operation.

However, I failed to restore the file system if /dev/vda6 gets damaged. I used an alternate superblock for fsck (one located on vdb2 or vdb3), but no avail. I lost information about the data stored on vdb2 and vdb3 (they can be found in lost+found, but name is lost). I didn't managed so far to recover the file system if the first disk (i.e. where the primary superblock is) failed. I still need to investigate what's wrong.

What do you think about these recovery possibilities? No point however that RAID+LVM looks safer.

Quote:
Originally Posted by DukeNuke2
how about opensolaris with ZFS? there are many tutorials on ZFS and how to build a home NAS system...
That could be definitively worse a try. But I'll first investigate on the system where I am most knowledgeable about.
 
PVCK(8) 						      System Manager's Manual							   PVCK(8)

NAME
pvck - check physical volume metadata SYNOPSIS
pvck [-d|--debug] [-h|--help] [-v|--verbose] [--labelsector] PhysicalVolume [PhysicalVolume...] DESCRIPTION
pvck checks physical volume LVM metadata for consistency. OPTIONS
See lvm for common options. --labelsector sector By default, 4 sectors of PhysicalVolume are scanned for an LVM label, starting at sector 0. This parameter allows you to specify a different starting sector for the scan and is useful for recovery situations. For example, suppose the partition table is corrupted or lost on /dev/sda, but you suspect there was an LVM partition at approximately 100 MB. This area of the disk may be scanned by using the --labelsector parameter with a value of 204800 (100 * 1024 * 1024 / 512 = 204800): pvck --labelsector 204800 /dev/sda Note that a script can be used with --labelsector to automate the process of finding LVM labels. SEE ALSO
lvm(8), pvcreate(8), pvscan(8) vgck(8) Sistina Software UK LVM TOOLS 2.02.95(2) (2012-03-06) PVCK(8)
All times are GMT -4. The time now is 01:35 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy