[Linux-cluster] EFI in CLVM

[Paras pradhan]

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?


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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-cluster/attachments/20110812/93e5f47e/attachment.htm>