Subject: Re: NetBSD iSCSI HOWTOs
To: Bill Studenmund <wrstuden@NetBSD.org>
From: Alistair Crooks <email@example.com>
Date: 02/28/2006 08:44:57
On Mon, Feb 27, 2006 at 08:39:34PM -0800, Bill Studenmund wrote:
> On Mon, Feb 27, 2006 at 05:48:25PM +1000, Ray Phillips wrote:
> > >I think there are a lot of RAID users out there who aren't familiar with
> > >buzzwords like ``The RAID5 Write Hole''...
> > I'm afraid I'm one of those. Could you elaborate on that please
> > Miles? Googling for the term didn't turn up much.
> > At the risk asking a dumb question, I suppose using iSCSI to access
> > disks across a network gives better performance than NFS or SMB/CIFS?
> > What sort of increase in speed could be expected?
> A way to look at iSCSI in comparison to an NFS server with local disk is
> that you push the file system out from the disk server (the iSCSI target)
> to the initiator (disk client, NFS server). Thus the CPU with the disks
> does less work, and thus can support more clients for the same CPU
There are some results (more pertinent to Disaster Recovery and
Business Continuity) in:
These show that, since iSCSI is a much lower-level protocol, it
is quicker than CIFS or iSCSI, especially taking advantage of
Multiple Connections per Session.
> > Are there other ways to restrict access to a NetBSD iSCSI target
> > apart of listing the IPs initiators may have in /etc/iscsi/targets?
> > Perhaps somehow using samba to authenticate users?
> You can't use samba to authenticate users using iSCSI. 1) there's no
> defined auth method, and 2) iSCSI initiators aren't samba users. :-)
It's always been a regret of mine that the people responsible for
security in the iSCSI RFC just didn't understand the question.
There's an excellent overview of the complete lack of any sort of
security whatsoever in RFC 3720 in:
In particular, iSCSI doesn't offer any security worth even mention of
the word. You *have* to use IPsec or a VPN to transfer the iSCSI
traffic. This is your data that you have to protect, and anyone who
can gain access to your iSCSI target has access to *all* your data.
> The canonical way to restrict access to an iSCSI target is to use CHAP.
Restricting access is one thing - protecting your data is another.
iSCSI is only part of the equation - OSD goes the whole way, but the
iSCSI proponents seem to have overlooked all of this.