[Linux-cluster] EFI in CLVM

[Jonathan Barber]

On 13 August 2011 04:24, Paras pradhan <pradhanparas at gmail.com> wrote:
> Alan,
> Its a FC SAN.
> Here is multipath -v2 -ll output and looks good .
> --
> mpath13 (360060e8004770d000000770d000003e9) dm-28 HITACHI,OPEN-V*4
> [size=2.0T][features=1 queue_if_no_path][hwhandler=0][rw]
> \_ round-robin 0 [prio=2][active]
>  \_ 5:0:1:7 sdt 65:48 [active][ready]
>  \_ 6:0:1:7 sdu 65:64 [active][ready]
> ---
>
> If I don't make an entire LUN a PV, I think I would then need partitions. Am
> i right? and you think this will reduce the speed penalty?

The (possible) speed penalty with a partition + LVM is because the
blocks in the LVM/filesystem aren't aligned with the blocks in the
storage system. So when you write a block in the the OS, the storage
system has to write to two blocks. You can overcome this by manually
aligning the partitions with the underlying storage.

You can also just not use any partitions/LVM and write the filesystem
directly to the block device... But I'd just stick with using LVM.

If you want to create a LV that uses all of the space on a VG, you can use:
# lvcreate -l 100%FREEVG -n $NAME $VGNAME

Do you see the same problem if you create the LV without CLVMD
running? This thread suggests it's possible to stop clvmd whilst the
cluster is running:
https://www.redhat.com/archives/linux-cluster/2008-November/msg00151.html

If you run "lvcreate -ddddddd -vvv ..." do you see any useful messages?

Cheers

> Thanks
> Paras.
>
>
> On Fri, Aug 12, 2011 at 8:39 PM, Alan Brown <ajb2 at mssl.ucl.ac.uk> wrote:
>>
>> On 12/08/2011 17:24, Paras pradhan wrote:
>>>
>>> Does it mean that I don't need mpath0p1 ? If its the case i don't need to
>>> run kpartx on mpath0?
>>
>> You still need kpartx, but that's a bit clunky anyway. Let dm-multipath
>> take care of all that for you.
>>
>> (The last time I used kpartx and friends was 2003. Dm-multipath and
>> multipathd are much more user-friendly. All you need then is multipath -v2
>> -ll to verify things are where they should be...)
>>
>>> And not having mpath0p1 will take away this device mapper ioctl failed
>>> issue when creating lvcreate?
>>>
>>
>> I think that's a separate issue. What's the underlaying structure? SAN?
>> FC? iscsi? drdb?
>>
>>> I am really confused why this lock has failed , also not sure if this is
>>> related to this >2TB LUN.
>>>
>>
>> It's not. Some of my LUNs are 25+Tb
>>
>
>
>
>>
>> FWIW having PVs on LUN partitions introduces a small but measurable speed
>> penalty over making the entire LUN a PV - this is mostly down to the small
>> offset a partition table adds to the front of the LUN.
>>
>
>
>
>
>
> --
> Linux-cluster mailing list
> Linux-cluster at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-cluster
>



-- 
Jonathan Barber <jonathan.barber at gmail.com>