Re: [Iscsitarget-devel] F7 Question on Disk Size

[Br E. <bre...@gm...>]

Ross,

If I understand your comment on using ScsiId, are you are suggesting
this in order provide consistant client device naming?  If so, I have
a udev rules script that does this by creating a device directory in
/dev/iscsi like "iqn.2007-01.com.abc:storage.readwrite.efg" based on
the iQN (iSCSI Qualified Name) from IET.  Perhaps my examples using
/dev/sde made it seem otherwise, but I in reality I'm not using
/dev/sdx devices.  Am I missing something?

Thanks,
Brent

On 6/5/07, Ross S. W. Walker <rw...@me...> wrote:
> > -----Original Message-----
> > From: isc...@li...
> > [mailto:isc...@li...] On
> > Behalf Of Br Ent
> > Sent: Tuesday, June 05, 2007 11:08 AM
> > To: isc...@li...
> > Subject: Re: [Iscsitarget-devel] F7 Question on Disk Size
> >
> > # cat /etc/ietd.conf
> > ## iSCSId Target Configuration File
> > #User ags
> > Target iqn.2007-01.com.affinitygs:storage.readwrite.oracle01
> >         Lun 0
> > Path=/dev/mapper/VolGroup00-LogVolORACLE01,Type=blockio,IOMode=rt
> > Target iqn.2007-01.com.affinitygs:storage.readonly.oracle01
> >         Lun 1
> > Path=/dev/mapper/VolGroup00-LogVolORACLE01,Type=blockio,IOMode=ro
> > Target iqn.2007-01.com.affinitygs:storage.readwrite.data01
> >         Lun 2
> > Path=/dev/mapper/VolGroup00-LogVolDATA01,Type=blockio,IOMode=rt
> > Target iqn.2007-01.com.affinitygs:storage.readonly.data01
> >         Lun 3
> > Path=/dev/mapper/VolGroup00-LogVolDATA01,Type=blockio,IOMode=ro
> > Target iqn.2007-05.com.affinitygs:storage.readwrite.linuxORACLE02
> >         Lun 4
> > Path=/dev/mapper/VolGroup00-LogVolLinuxORACLE02,Type=blockio,IOMode=rt
>
> I would seriously advise you set ScsiId= and assign a unique ID to each
> LUN as most SCSI implementations will rely on those remaining the same
> during fail-over/multi-pathing/reservations and storage upgrades could
> mess those up.
>
> You don't need to set IOMode=wt for write-through, that's the default,
> but if you did, it would be 'wt' instead of 'rt'
>
> > # cat /proc/net/iet/volume
> > tid:5 name:iqn.2007-05.com.affinitygs:storage.readwrite.linuxORACLE02
> >         lun:4 state:0 iotype:blockio iomode:wt
> > path:/dev/mapper/VolGroup00-LogVolLinuxORACLE02
> > tid:4 name:iqn.2007-01.com.affinitygs:storage.readonly.data01
> >         lun:3 state:0 iotype:blockio iomode:ro
> > path:/dev/mapper/VolGroup00-LogVolDATA01
> > tid:3 name:iqn.2007-01.com.affinitygs:storage.readwrite.data01
> >         lun:2 state:0 iotype:blockio iomode:wt
> > path:/dev/mapper/VolGroup00-LogVolDATA01
> > tid:2 name:iqn.2007-01.com.affinitygs:storage.readonly.oracle01
> >         lun:1 state:0 iotype:blockio iomode:ro
> > path:/dev/mapper/VolGroup00-LogVolORACLE01
> > tid:1 name:iqn.2007-01.com.affinitygs:storage.readwrite.oracle01
> >         lun:0 state:0 iotype:blockio iomode:wt
> > path:/dev/mapper/VolGroup00-LogVolORACLE01
>
> (Warning: Slighly off-topic content below!)
>
> You know we need a lot more information in the iet volume output. I think
> a 'sectors' field like nullio would be useful as well as a 'reserved'
> field that indicates if a reservation is being held and maybe 1 or 2 iotype
> specific ones like 'max_req' for max request size when using blockio, and
> maybe a 'dev_t' field for fileio that can give a 'b' for block, 'f' for
> file.
>
> Without me looking at the code, who here remembers what the 'state' field
> is suppose to convey?
>
>
> -Ross