iSCSI for Mac OS X?

CoffeePlease asks: "Is anyone aware of development going on for iSCSI drivers for Mac OS X? I really need this but it's only out for Windows and Linux so far. I can't use the Linux drivers - they might run, but only as a command-line process, and I need other software to recognize the drives."

Comments

Not to my knowledge

[Matthias Wiesmann]

• There is no mention of iSCSI on apple's site, and I never heard of apple supporting iSCSI.
• You cannot run Linux drivers on Mac OS X, drivers is one area where Darwin is very different from Linux. You might have more luck with BSD drivers.
• Running the drivers as command line makes little sense: drivers don't have much interfaces. You might need the command line to start or install drivers.
• Assuming an iSCSI driver existed for Mac OS X / Darwin, then the system could see a remote device and handle it. Assuming the file-system on this device would be supported by Darwin then all applications, with or without GUI would 'see' this file-system.

Re:Not to my knowledge

[Draoi]

You might have more luck with BSD drivers

Nope, unfortunately. File system drivers for MacOS X would have to be written as a kext and would be IOKit-based. Totally un-BSD ...

My first point of call would be the Darwin-Drivers mailing list and archives.

Re:Not to my knowledge

[questionlp]

It may not be Mac OS X or Darwin-specific, but it seems that Intel is working with Wasabi Systems/NetBSD to work on getting iSCSI to run on NetBSD. Some of this may work up to Darwin, then into Mac OS X... but it will take a while, mostly when Apple is focusing on Fibre Channel with their XServe RAID units.

Re:Not to my knowledge

[ZigMonty]

Incorrect. Although device drivers are IOKit-based, the VFS layer of darwin (filesystems) is almost straight FreeBSD. There are problems with the fact that Darwin's locking is different and probably VM issues. You definitely can't just take a FreeBSD filesystem and throw it into Mac OS X but it would only be a porting effort, not a rewrite.

Re:Not to my knowledge

[mkldev]

File system drivers for MacOS X would have to be written as a kext and would be IOKit-based. Totally un-BSD ...

If it were a file system, you would be wrong (since the VFS layer is basically BSD), but it isn't a file system; it's a block device. So yes, it would be an I/O Kit KEXT.

However, to say that it's "totally un-BSD" is a stretch. BSD drivers are relatively easy to port to Mac OS X if they are written correctly. The wrapper tends to be relatively small, with additional changes needed for synchronization where applicable.

iSCSI isn't even fully standardized!

[Anonymous Coward]

They just just just agreed on the final technical specs and most certainly haven't gotten to officially ratifying those specs as the standard yet.

Re:iSCSI isn't even fully standardized!

[Anonymous Coward]

You mean like 802.11g???

iSCSI on Linux...

[molo]

Looks like there is a project that is implementing it as a kernel-level driver (as it should be, IMO). It exports the device as /dev/sda (etc.). It certainly seems to be in active development.

http://linux-iscsi.sourceforge.net/

Re:iSCSI on Linux...

[battjt]

Looks like an iSCSI client. How about an iSCSI server?

Joe

Re:iSCSI on Linux...

[shawnce]

The disk drives, block serving NAS boxes, protocol bridges, disk arrays, etc. are your iSCSI servers.

You normally wouldn't run a iSCSI server on a server box, better to run some type of file server on those.

Re:iSCSI on Linux...

[battjt]

Wouldn't you run iSCSI as a server process for the same reasons you would run a network block device (nbd) server?

The NBD stuff looks pretty fragile; I was hoping someone would build a more robust iSCSI server for Unix.

Yah, I know. If I had the time, I would work on it.

Joe

oh, whatever

[Twirlip of the Mists]

Nobody "really needs" iSCSI. iSCSI isn't real yet. It's still one of those "coming soon" things, like Infiniband. And we saw how well Infiniband worked out.

iSCSI is just another way of solving a problem that's already been solved in any number of other ways. You need to attach a computer to some storage. Okay. You can use direct-attach FireWire storage. That has the advantage of being absolutely bullet-proof. Or you can use Fibre Channel to attach to a switched fabric. That works fine, too; just present a LUN to the Mac and let it format and mount it. Or you can use a network storage technology, like AppleShare or NFS. Those work fine, too, and the Power Macs, PowerBooks, and xServes are all shipping with 1000BASE-T, so that's not a problem.

There are any number of ways to ameliorate your so-called "real need" for iSCSI. These work today. Use them.

Re:oh, whatever

[aderusha]

1) firewire - no managment, just loose drives attached to single machines. might as well suggest a usb memory stick. firewire drives don't make a san.

2) fibre channel - cost of entry approaching $50k. that adds up to about 50k reasons not to use it on a home machine or small network.

3) network storage - not really a block level disk access technology, is it?

i think the real reason is that very few people are using macs in a data center serving up real applications to lots of clients - the sorta place where a well managed SAN makes sense. now that the draft standard has been finalized (but not ratified), i imagine that you'll see iSCSI becoming more commoditized and more software being made available for more OSs.

note that the windows and linux software packages are only iSCSI initiators - i haven't seen any software based iSCSI targets. this means that even if you did port the code to Darwin you'd still have to have some storage device out there speaking iSCSI to point your mac at.

Re:oh, whatever

[gerardrj]

Eccept that in my experience most Datacenters are migrating to net attached storage. People are tired of SANs, the high chost of parts and maintenence, the difficultly and expense of backing up, etc.
Sure... it SOUNDS great to have 5TB of storage in one unit, but just exactly how do you keep current off-site backups? Oh... that's right... you maintain another 5TB unit in another location and run a dedicated T3 between them, yea... THAT'S affordable.

The SAN was a great idea, Fiber Channel was a great idea, but it never reached critical mss, and now distributed network storage is taking over. iSCSI will propbaly make some inroads, but it will never replace a simple device with network ports actining as a server. The latter is cheap, esily understood, easily maintained, provides 95% of the functionality necessary to any IT department, and the clients are built in to every major OS on the market.

Re:oh, whatever

[Anonymous Coward]

------
1) firewire - no managment, just loose drives attached to single machines. might as well suggest a usb memory stick. firewire drives don't make a san.
------

no, firewire drives can be attached to many machines
at the same time. there -are- firewire san solutions out
there right now.

------
2) fibre channel - cost of entry approaching $50k. that adds up to about 50k reasons not to use it on a home machine or small network.
------

no, have a look at Apple's Xraid box. Much cheaper than
$50k.

------
i think the real reason is that very few people are using macs in a data center serving up real applications to lots of clients - the sorta place where a well managed SAN makes sense. now that the draft standard has been finalized (but not ratified), i imagine that you'll see iSCSI becoming more commoditized and more software being made available for more OSs.
------

I think the main reason that macs are doing that job
is that there haven't been any mac capable of doing
that job.

Re:oh, whatever

[Oculus Habent]

Perhaps CoffeePlease could be OK for now with something simpler.

Set up NetBoot on the Macs, and export the file system from whereever the hell you want.

It isn't the perfect solution, but it might just get you what you need in the meantime.

Re:oh, whatever

[Anonymous Coward]

There are a lot of apps, though that demand disk-level access to things. Sure, you could push a lot of things to DFS (in the windows world)--even, conceivably a nice system like an XRAID. But for systems that demand a disk level access, such as SQL, Exchange, etc., a SAN or Server attached storage is the only way to go now.

iSCSI would change that, and bring the power of SAN-type storage to a much better budget point. It's true, SANs are too limiting and too finicky and way way too expensive. That's by the XRAID looks appealing and would be more appealing if an attached XServe could serve up the disk space as an iSCSI drive.

I'm less interested in seeing the proliferation of iSCSI clients, and much more interested in the proliferation of iSCSI target software. It'll make storage that much more flexible.

Re:oh, whatever

[CoffeePlease]

Um - I kinda do need it. I have been given an account on an iSCSI server, and will be given the drivers on my PC next week. Unfortunately the machine I could really best use it on is the Mac - where I do most of my video work.

Re:oh, whatever

[benh57]

Your fibre channel numbers are way off. You can get an XServe RAID Fibre Channel and 2.5TB for $10999. The FC host PCI card from apple is $499. 400MB/s throughput.

Re:oh, whatever

[Anonymous Coward]

The 50K number isn't off the mark really. The $12,000 for XRAID buys you just two arrays attachable to two servers. If you want to put the XRAID behind one or two (for redundancy) fiber channel switches. Those run as much or more than the XRAID itself.

One of the benefits of iSCSI would be that the very pricey FC Switched network would be unecessary -- you could leverage your LAN.

Re:oh, whatever

[Anonymous Coward]

Again, Two arrays attached to two servers does not a SAN make. You'll need some very expensive Fiber Channel switches and numerous Fiber Channel cards to spread that investment in disk space around to multiple servers.

Re:oh, whatever

[hype7]

1) firewire - no managment, just loose drives attached to single machines. might as well suggest a usb memory stick. firewire drives don't make a san.

I don't know what you mean by that, but there is some pretty cool firewire stuff over here that looks to be a bit better than a usb memory stick.

-- james

Re:oh, whatever

[aderusha]

from the link you've provided, i find one SAN machine - the sancube, which actually makes a SAN on firewire.

except the max capacity is 720GB and it only supports a maximum of 4 hosts.

hardly a SAN...

Re:oh, whatever

[CoffeePlease]

Firewire is great - I love it. The drives are dirt cheap. Firewire connections are fairly trouble free, except on windows. But not really fast enough for working directly with the drive in finalcut pro.

Re:oh, whatever

[gerardrj]

But neither SQL nor Exchange require disk level access. Neither app has special version for ATA, SCSI, SAN or NAT storage space. VERY few apps actually require phyical device access (sending commands directly to hardware instead of through the OSI abstractions), or even block level access.
The few that I can think of are disk repair an maintenance utilities.
Running SQL servers over NAT, NFS or any other sort of "soft" mount works just fine.

Re:oh, whatever

[drinkypoo]

IEEE1394B is peer to peer. SAN management is a job for a user space tool. Fiber channel is not a solution because of the immense expense of the hubs, transceivers, enclosures, et cetera, only the people who have already bought a complete SAN can afford it :P

Firewire makes the most sense; 128 devices per channel (if one counts "the" controller, 127, but 1394B is peer to peer so let's just call 128 what it is, the number between 127 and 129) and with speeds of 3.2Gbps in limited implementations today, and 1.6Gbps more readily available (and on copper, 3.2 requires fiber at this stage.)

The big missing piece for replacing IDE, SATA, Fiberchannel, and all flavors of SCSI except Ultra320 (which is still faster than the fastest 1394) is 1394-native hard drives. Why is no one making these? It would seem that there is a market, if for no reason other than simply lowering the cost of 1394-attached peripherals.

Re:oh, whatever

[shawnce]

I got a almost new quality 16 port Brocade 2800 switch of off eBay, fully load with GBICs for around 4k, add on about 400-600 per host for adapters, and 5k-11k for something like Apple's xRAID you can get into a FC SAN for much less then 50k.

If you want 2gig fibre channel it would cost you of course more for the switch (2-3x currently).

Not that it is a cost effect thing to do for small SANs... iSCSI isn't that cheap either but in theory you do save on at least the switch costs (most companies are making iSCSI adapters instead of normal NICs for performance reasons).

Re:oh, whatever

[shawnce]

This doesn't fully match with my experience and I work for HP in their storage software division... fortune 50, 100 and many 500 are using and or starting to setup storage networks based on Fibre Channel (not much iSCSI yet).

Most of the major data centers in the world are using FC interconnects and large storage arrays (5+ TB per array, the bigger (in capacity not physical size) the better generally). The trend is towards putting the data in storage arrays external from the servers, think about blade servers for example.

So in other words toward using storage networks regardless if they are based on FC interconnects, iSCSI, etc.

---

Also not what your point is about T3 and 5TB replicated storage... Many companies do that with far larger amounts of storage using metro fiber not T3s. This is not an Fibre Channel issue but a data desaster recover issue.

Re:oh, whatever

[britt]

Not true. Exchange 2000 will only run on direct attached storage. I'm not sure about SQL server. It will only run on NTFS, CIFS will not work.

Re:oh, whatever

[gerardrj]

Which is one of the major reasons that people have not been migrating to E2K as quickly as MS would have liked.

But the still... exhange is NOT accessing the disk directly, MS just did a brain-dead thing and forces E2K to use the DASD storage stack instead of the one level higher at the "volume" level where total abstraction is possible. One major reason MS did this was to lock people in to their proprietary Microsoft Cluster Server solutions and higher licensing fees for those components. There is no technical reason the E2K must use local storage.
At least that'm my understanding of the state of things.

Re:oh, whatever

[sean23007]

You talk about the alternatives being too expensive to use at home, but also that nobody uses Macs in a data center... It seems that you're just throwing things around.

Re:oh, whatever

[aderusha]

actually, i think it's very consistent: given that a) he's asking "ask slashdot" instead of somebody like EMC, it's probably not for a major data center. and b) there aren't a hell of a lot of datacenters out there hosting large scale mac server installs (yet).

which is why iscsi would actually be nice on a mac, as a software implementation would probably be cheap and would utilize commodity hardware and would be totally accessible for the home user. i manage a number of intel systems attached to an emc SAN at work, and i'd love to be able to implement something similar at home myself, which has me watching the emerging iscsi standard very closely for these same reasons - i just don't have the quid to drop a symmetrix in at home...

Re:oh, whatever

[anothy]

first:

...about 50k reasons not to use it on a home machine or small network.

then:

...very few people are using macs in a data center serving up real applications to lots of clients - the sorta place where a well managed SAN makes sense.

uh, which one is it, then? if you're working in a real data center, you're presumably not in your home.
and, not incidently, i've still yet to have it explained to me why a block level network storage system is a good thing as compared to a network file system (although not NFS particularly), other than for developers who can't wrap their minds around any model that doesn't involve every PC having a "disk".

Re:oh, whatever

[anothy]

iSCSI is just another way of solving a problem that's already been solved in any number of other ways.

absolutely right. and not even an improvement. i'd say quite the oposite. what's so great about the SCSI command set that makes people think it'll be such a wonderful networked protocol? there's lots of things it doesn't do that you'd like a network protocol to do. presumably many of these are addressed by the "i" up front, but why do this stupid layering? is elegance totally lost on modern programers?
this all doesn't even get into the question of whether a block-level network storage system is a good thing. can someone explain to me why it's an improvement over a good network file system? and please don't talk about problems with specific network file systems. we all know NFS sucks.

Why not Linux?

[mdielmann]

Obligatory comment on why command-line is more powerful, and why wouldn't you want that...

Let me get this right...

[hmccabe]

it's called iSCSI and it's on every platform but Apple's? It seems a bit like Apple naming rendezvous GnuIPdetect.

Re:Let me get this right...

[Anonymous Coward]

I think most of the people here are very confused about what iSCSI is. It is a protocol that will bridge IP and SCSI. Basically, this means that if you purchase an iSCSI device you can attach that device to your network and attach your SCSI devices to the other side of the device. Now your SCSI devices look like network devices such as harddrives or the like.

iSCSI has NOTHING to do with Apple. It is just the name of the IP/SCSI protocol...

Re:Let me get this right...

[kraksmoka]

actually, get this right. rendezvous is based on (and quite heavily supported) by the zeroconf working standards group. yes, it can even work on winblows, theoretically speaking, of course.

No iSCSI Targets for Linux?

[eric2hill]

Sigh

Re:No iSCSI Targets for Linux?

[aderusha]

from the link:

Note: This application is intended for test environments only. It has no warranty or support.

this doesn't engender much confidence in a $1000 adapter.

Re:No iSCSI Targets for Linux?

[FredFnord]

I'm trying hard to figure out what you expect for FREE.

--Fred

Re:No iSCSI Targets for Linux?

[britt]

Intel has tested this with more than just their target test tool...

Network Appliance released their iSCSI target system which is qualified with this adapter.

OT? But I gotta know

[kwerle]

What on earth do you want to use this for?

Whoa. Are you confused.

[porkchop_d_clown]

As some writing SRP drivers for a living - iSCSI is a protocol that allows you to send SCSI commands between to machines linked by TCP/IP. It doesn't "bridge" IP and SCSI - it's not like you can use it to ping your hard drive.

The intent of iSCSI is to allow people to build SANs without having to shell out actual money for a fibre channel installation.

Re:Whoa. Are you confused.

[afidel]

Or to use something much more robust than any fibre channel installation like say a truely well designed TCP/IP network. Not to mention that 10Gig Ethernet is already here so core speeds are 5X faster for the iSCSI solution vs a fibre channel solution.

Re:OT? But I gotta know

[CoffeePlease]

Video. Those files are big! I use a tape drive for backing up, but while projects are active, it's handy to have everything online. I also have lots of regular drive space, of course.

We're not dead yet!

[Anonymous Coward]

We're actually feeling much better!

PC

[56ksucks]

Guess you should have bought a PC. Or, run Linux on your Mac.

Re:OT? But I gotta know

[Anonymous Coward]

How is this used? Where does one find iSCSI storage?

What about other network storage options? There is 10 TB of publicly available storage scattered all over the US, Europe and Asia for temporary use. Check out http://loci.cs.utk.edu.

wait a minute

[commodoresloat]

are you saying Apple doesn't support iSCSI? how is that possible? It starts with an "i" followed by a capital letter? How could they not support it?! Help, my world is collapsing around me!

You don't "need" iSCSI.

[Anonymous Coward]

Yes, those files are big. But if you're talking about real video (I don't mean RealVideo, just real video), and not digitised film, those files don't require a very high speed by today's standards. DV needs about 4 MB/s, uncompressed video (YUV 4:2:2) needs about 19 MB/s.

If you need to access the video from several editing stations, simply use network attached storage (ie, a video server) with gigabit (or even base-100) ethernet.

I don't know how things work in Macs, but in Windows (2000/XP), you can even "attach" a local directory to a network path (so "c:\video" can actually reside in the video server).

In my company we have a small video-editing department (4 stations), and we have no problems playing back video from the other stations' drives (and this is using a regular base-100 LAN).

I may start on a driver for QLogic's iSCSI cards

[shawnce]

I am about to finish work on a Fibre Channel driver for Mac OS X and QLogic's SANBlade family of adapters. Just waiting on my Apple xRAID to show up so I can finish testing (my current test array is toast, aka expensive brick).

Anyway I have been looking at writing or extending the driver to support QLogic's iSCSI capable adapters.

Cheap solution, if not fast:

[porkchop_d_clown]

Set up your PC to share the iSCSI drives and use windows file sharing to get to them.

Not the fastest solution, but it will work around the issue.

Ah, yes. Nothing like comparing Apples to Oranges.

[porkchop_d_clown]

Raw bit rates don't control data rates. Little things like latency, overhead of the protocol, etc., etc..

Look at Firewire 1.0 vs USB 2.0 - 2.0 has the higher bit rate, but even regular Firewire will give you better throughput.

Re:Dear Slashdot

[Anonymous Coward]

C'mon. It is funny. Ha ha.