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

On Tue, Feb 15, 2005 at 10:43:03AM +0100, Wojciech Puchar wrote:
> >left.
> >
> >Sure, you can eliminate the CPU usage with iSCSI by purchasing an=20
> >expensive iSCSI offload adapter, but now where is the cost savings?  The=
y=20
> >go "*poof*", as you observe.  Sure, you save on the FC switch, but a=20
> >high-end Gig-E switch that can support jumbo frames and traffic shaping=
=20
> >ain't exactly chopped
>=20
> could you please explain why to "save costs" instead of just not making=
=20
> costs =3D not introducing extra architecture, extra protocol, extra new=
=20
> network standard?

You're making the wrong comparison. Comparing FC and iSCSI makes sense as=
=20
they are both SAN protocols. Comparing either with NFS or CIFS is wrong as=
=20
the latter are NAS protocols. They do different jobs.

NAS exports a bunch of files, with full file semantics on each. It solves=
=20
the problem of extending a multi-user file system (i.e. with ownership &=20
ACLs of some sort) to multiple computers. SAN technologies (FC and iSCSI)=
=20
solve a different problem. They solve the issue of disks having to connect=
=20
to the computer using them. 1) Say you have a server that is so important=
=20
you buy another as a hot space. If the first fails, you have to connect=20
the disks to the hot space for it to be able to work. With SPI (parallel=20
SCSI), that means weird cabling. 2) SPI has a cable length max on the=20
order of a few meters. Thus all your disks have to fit next to your=20
computer. With a lot of disks, that becomes quite an issue.

One of the other advantages of iSCSI (or FC) is that in the case where you=
=20
have a number of independent clients connected to the same server, using=20
SAN protocols pushes the file system processing out to the clients,=20
reducing the load on the server. Thus the same level of server should be=20
able to support more iSCSI clients. This idea of course assumes that=20
FS-related processing is significant on the server. With slow-enough=20
disks, of course, the disks become the limit. :-)

Take care,

Bill

--OBd5C1Lgu00Gd/Tn
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFCE9AGWz+3JHUci9cRAtHBAJ4vlPT074NlXbxyW8wajIRa2fspgwCeMp2g
5PhO21G9OGeO3eBjWz2zY0Q=
=3ZYc
-----END PGP SIGNATURE-----

--OBd5C1Lgu00Gd/Tn--