[stgt] [linux-iscsi-users] 2TB+ LUNs?

[Ray Van Dolson]

On Tue, Jan 27, 2009 at 09:14:34PM -0800, FUJITA Tomonori wrote:
> On Tue, 27 Jan 2009 16:56:51 -0800
> Ray Van Dolson <rvandolson at esri.com> wrote:
> 
> > On Tue, Jan 27, 2009 at 04:35:24PM -0800, Richard Sharpe wrote:
> > > On Tue, Jan 27, 2009 at 4:04 PM, Ray Van Dolson <rvandolson at esri.com> wrote:
> > > > On Tue, Jan 27, 2009 at 02:37:48PM -0800, Richard Sharpe wrote:
> > > >
> > > > Thanks for the reply Richard.
> > > >
> > > > I don't see anything at all really in the target's syslogs, nor in
> > > > dmesg.  I ran tgtd in debug mode in the foreground, but it was very
> > > > noisy (obviously) and I wasn't really sure what I was looking for.
> > > >
> > > > I've also taken a packet dump of a connection.  Maybe someone can find
> > > > something useful from it?
> > > 
> > > Ahhh, fire it up in WireShark and check to see if the
> > > ReadCapacity(16)s were making it onto the wire. They are actually
> > > ServiceActionIns or something with an action of ReadCapacity.
> > > 
> > > If they were making it onto the wire, then that might point the finger
> > > at the target ...
> > > 
> > > If not, it would suggest that the initiator is at fault.
> > > 
> > 
> > Did a search in the packet bodies (tcpdump'd with -s 0 btw) for both
> > the string "ReadCapacity" as well as "ServiceActionIns" and didn't come
> > up with anything.
> > 
> > If anyone wants to take a look for themselves, feel free to take a
> > gander at the dump URL I posted previously.
> 
> Hmm, looks like the initiator sent SAI_READ_CAPACITY_16 (77th packet).
> 
> I thought even very old STGT can handle this (you use 20070620)
> because the code is based on IET but I might be wrong. Try the latest
> STGT,
> 
> http://stgt.berlios.de/releases/tgt-0.9.3.tar.bz2
> 
> 
> With it and open-iscsi, I got:
> 
> scsi0 : iSCSI Initiator over TCP/IP
> scsi 0:0:0:0: RAID              IET      Controller       0001 PQ: 0 ANSI: 5
> scsi 0:0:0:1: Direct-Access     IET      VIRTUAL-DISK     0001 PQ: 0 ANSI: 5
> Driver 'sd' needs updating - please use bus_type methods
> sd 0:0:0:1: [sda] Very big device. Trying to use READ CAPACITY(16).
> sd 0:0:0:1: [sda] 34359738368 512-byte hardware sectors (17592186 MB)
> sd 0:0:0:1: [sda] Write Protect is off
> sd 0:0:0:1: [sda] Mode Sense: 79 00 00 08
> sd 0:0:0:1: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> sd 0:0:0:1: [sda] Very big device. Trying to use READ CAPACITY(16).
> sd 0:0:0:1: [sda] 34359738368 512-byte hardware sectors (17592186 MB)
> sd 0:0:0:1: [sda] Write Protect is off
> sd 0:0:0:1: [sda] Mode Sense: 79 00 00 08
> sd 0:0:0:1: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
>  sda: unknown partition table
> sd 0:0:0:1: [sda] Attached SCSI disk
> 

Well, I found a newer version of scsi-target-utils on RHN in the
cluster channel -- scsi-target-utils-0.0-5.20080917snap.el5.  Upgraded
my version and everything seems to be working now (I also have access
to an actual target configuration file instead of calling tgtadm
manually).

Output on the initiator now looks as follows:

   sdb : very big device. try to use READ CAPACITY(16).
   SCSI device sdb: 8589934592 512-byte hdwr sectors (4398047 MB)
   SCSI device sdb: drive cache: write back
   sdb : very big device. try to use READ CAPACITY(16).
   SCSI device sdb: 8589934592 512-byte hdwr sectors (4398047 MB)
   SCSI device sdb: drive cache: write back
    sdb: unknown partition table
   Attached scsi disk sdb at scsi7, channel 0, id 0, lun 1
   Attached scsi generic sg3 at scsi7, channel 0, id 0, lun 1,  type 0
   disk at /devices/platform/host7/target7:0:0/7:0:0:1

(As you can see, I upped the size of the exported LUN also).

Thanks all for helping me track this down!  The CPU load on my target
system is pretty high when creating the filesystem on the initiator.
Maybe I should upgrade to the latest stgt to see if I can get better
performance.

Anyways, thanks all.

Ray
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html