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 <[email protected]> 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 [email protected] https://www.redhat.com/mailman/listinfo/linux-cluster
