--u65IjBhB3TIa72Vp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 14, 2005 at 07:16:45PM -0800, Jason Thorpe wrote:
>=20
> On Feb 14, 2005, at 5:18 PM, Daniel Carosone wrote:
>=20
> >On their sales quotes for the other
> >side, iSCSI replaces somewhat expensive FCAL HBA's with even more
> >expensive HBA's that offload iSCSI and TCP processing to the card.
>=20
> Perhaps we're getting off on a tangent here, but...

Yeah, but I bet it'll be fun. So let's go. :-)

Oh, and while I'll mention some things I think you (Jason) didn't mention,=
=20
I think we mostly agree. :-)

> As I see it, one of the main flaws of iSCSI is the "software-ness" of=20
> it.  It's not a flaw in the protocol, but it's a flaw when you consider=
=20
> the expectations people have of their storage system.  They want=20
> 110MB/s for each Gig-E port, but that comes with a CPU usage cost, a=20
> cost that you do not pay with FC because FC offloads all of that=20
> transport and link processing.  Sure, you get the performance you=20
> expect out of your storage system, but you don't get the performance=20
> you expect out of the application running on the hosts that want to=20
> talk to the storage system, because they don't have much CPU left.
>=20
> Sure, you can eliminate the CPU usage with iSCSI by purchasing an=20
> expensive iSCSI offload adapter, but now where is the cost savings? =20
> They go "*poof*", as you observe.  Sure, you save on the FC switch, but=
=20
> a high-end Gig-E switch that can support jumbo frames and traffic=20
> shaping ain't exactly chopped liver...  Nevermind that to get the=20

One thing that I think iSCSI will have going for it is that while you're=20
right about the needs of the switches, Ethernet will have a lot more=20
competitive drive to reduce cost than will FC. So I think things will get=
=20
better in the future. :-) Yes, FC will get cheaper, but there will be more=
=20
things driving Ethernet down so I think it'll win.

> performance of one FC port, you need *TWO* Gig-E ports.  And forget=20
> about having a transaction latency as low as FC... iSCSI's protocol=20
> overhead is just plain higher (Ethernet, IP, TCP, *and* the iSCSI=20
> transport protocol).

Yes, transaction latency will be an issue. iSCSI will really need lots of=
=20
outstanding transactions.

> >If you want all the performance and throughput all the way through,
> >you pay that price.  If you don't need it, but you still want some of
> >the virtualisation flexibility and/or bulk capacity, options and
> >offerings are limited.
>=20
> I personally see iSCSI's niche as being "really cheap, moderately=20
> performing, expandable bulk storage".  Data archiving, etc.  "I need to=
=20
> put it away for 7 years, never touching it, until it's time to erase=20
> it."

I agree with you about the performance levels, but I think that there's a=
=20
lot more in that range. Say for the virtualizing and scaling on demand=20
range. Folks are happy with local disks that get say 30 MB/sec, and iSCSI=
=20
can do that easily. So there could be a lot of options where iSCSI is=20
"good enough." :-)

> >The RAID controllers are getting the smarts, and are learning to speak
> >iSCSI for such purposes as cross-site replication.  Cluster
> >filesystems on hosts, slowly, too.
>=20
> Cluster file systems on hosts don't need to speak iSCSI.  To any=20
> clustered file system, iSCSI looks *exactly* like FC, except for the=20
> use of IQNs rather than WWNs for LU naming.  As for cross-site=20
> replication, I don't see iSCSI as being particularly valuable for that.=
=20
>  From my perspective, this is best done at the FILE layer, *not* the=20
> block layer.

I agree I'd much prefer file-level backup. I think iSCSI's value in remote
replication is that it provides a transport on which we can build the file
mirroring. With a simple TCP connection, you have reached your storage=20
server. :-)

Yes, there are other options. CIFS and NFS can go over TCP too. And some=20
folks may prefer that. But iSCSI just seems to make more sense for remote=
=20
replication, at least as a transport. :-) But then again, I'm biased.

Take care,

Bill



--u65IjBhB3TIa72Vp
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFCEXDuWz+3JHUci9cRAokDAJ9NyaMcVy1/7cAXamJKJaHmdx3/bgCeINcr
cwabMQ28CwU/OWesHMuXJgo=
=IzKu
-----END PGP SIGNATURE-----

--u65IjBhB3TIa72Vp--