Hi Brett and thanks for the reply:

On Saturday 25 September 2010, Brett Johnson wrote:
> As I recall, you usually can't put /boot in an LVM partition because you
> need to read /boot to load your LVM driver.  Doing so will make your system
> not boot.
I suppose that explains (for non-PXE) why having /boot as a separate array would
be better than having /boot as part of /

> 
> A quick search turned up this:
> http://www.tldp.org/HOWTO/LVM-HOWTO/benefitsoflvmsmall.html.  It claims
> bootloaders don't understand lvm partitions (thus don't put /boot in an
> LVM).
> 
> As for the errors in fdisk, my understanding is you shouldn't use fdisk to
> modify /dev/md as raid devices don't contain true partitions.
> You can use fdisk to modify your other partitions, but if you touch /dev/md 
> and write it could blow away your LVM setup.
My understanding now is that you can't fsck with LVM except the logical volume 
/dev/mapper/etc
but i see plenty of refs on the net to fsck'ing arrays; heck some fs's would be 
spread out across
any number of physical partitions, right; so it couldnt be done otherwise 
unless its just raid1?

Just seeing boot errors (automatic fsck),  or running "fdisk -l" and seeing not 
just drive partitions but 
arrays, that got me googling and the majority of replys2forums said ignore for 
your stated reasons;
but combined with the possibility of setting /etc/fstab so that the fsck runs 
on reboot
and the (warning?) of a (raided) partition not falling on cylinder boundaries, 
made me
want to inquire here.

Again, the conventional widsom i found was clear: create array first, then 
format it ("mkfs.ext4 /dev/md0")
So while md devices aren't supposed to have a partition table on them they must 
have a FS

At issue is when the partition table and the superblock don't agree on the 
filesystem size,
 when something prob went wrong during the array creation and the superblocks 
overlap with the filesystem.

The best answer ive found to date is to non-destructively fsck the array and 
resize it then fsck again:
e2fsck -cc /dev/md0; resize2fs /dev/md0; fsck -f /dev/md0
may be non-destructive, but is pretty disk intensive, and resizefs also has its 
perils

So if opting for a huge LVM2 array, and not being able to fsck it and hoping 
dev/mapper will fix/repair
any volume errors on a failing drive?  Is LVM worth it? Has volume recovery 
(ignoring snapshots) been
problematic for anyone here using fsck?


Thanks again,

Rion


> 
> Again, someone else feel free to | in if I've said something incorrect.
> 
> --
> Brett Johnson
> simpleroute | 1690 Williston Road | South Burlington, VT 05401
> tel: 802-578-3983 | email: [email protected] | web: simpleroute.com
> 
> 
> 
 



-- 
                                     web: http://dluz.com/
                                     AIM/Jabber/MSN/: riondluz
                                     Google: xmpp:[email protected]
                                     email: riondluz_at_gmail.com
                                     Phone: 802.644.2255
                                     http://www.linkedin.com/pub/6/126/769

CLI forever!  

                 L I N U X       .~.
                  Choice         /V\
                 of a  GNU      /( )\
                Generation      ^^-^^
                                POSIX
                                RULES
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to