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@xxxxxxxxxxxxxx> wrote:
On 12/08/2011 17:24, Paras pradhan wrote:You still need kpartx, but that's a bit clunky anyway. Let dm-multipath take care of all that for you.
Does it mean that I don't need mpath0p1 ? If its the case i don't need to run kpartx on mpath0?
(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...)I think that's a separate issue. What's the underlaying structure? SAN? FC? iscsi? drdb?
And not having mpath0p1 will take away this device mapper ioctl failed issue when creating lvcreate?
It's not. Some of my LUNs are 25+Tb
I am really confused why this lock has failed , also not sure if this is related to this >2TB LUN.
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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
