Alright folks, here’s the big event/challenge. How can we get drobo FS to run iSCSI target/initiator software. Anyone up for it? I don’t see why it wouldn’t work. I just don’t think anyone has addressed it. I’m not a programmer otherwise I would be on it already. However, I’m a good collaborator and would be able to do some work(testing/troubleshooting/grunt work) All we need now are a few good programmers. What do you say? I’ve looked around quite extensively and I wasn’t able to find anything on this subject.
The problem you will run into is that ISCSI is a protocol.
The Drobo FS does not use the ISCSI protocol.
The Drobo FS uses TCP/IP.
Thanks for letting me down gracefully:)
but doesn’t ISCSI use TCP/IP? I’m guessing there’s a big fat reason why this can’t be done. Your input is appreciated:)
I do apologize. ISCSI is part of TCP/IP. The Drobo FS does not support this protocol.
I always like when someone tells me that something is not supported. It tickles my hacker bone.
So I did some digging and it seems that (overly simplifying it) iSCSI is a glorified NFS.
According to this guy, you’ll get some performance improvement over NFS, but nothing to write home about (up to 30% in some cases, but worst on others).
I also found a paper (PDF), that compares iSCSI with NFS and reaches this conclusion (emphasis mine):
I even found a pretty graph that confirms what the paper said. Bottom-line is that NFS and iSCSI are toe-to-toe in the most common scenario.
The major problem I foresee with this idea is the same that already exists with the NFS server available for the FS (uNFS3): those are userland implementations, not kernel implementations.
As pointed out by kbradley, the FS does not have kernel support for iSCSI, and thus we’ll have to run it in userland. Assuming that it is possible to cross-compile it (I honestly have no clue), that means performance will be just as bad as NFS, SMB or AFP, since all of those run in userland.
In other words: why go through the trouble of cross-compiling this if there is no (meaningful) performance gain? Is there any specific functionality of iSCSI that you need?
wow thanks for the thought out reply:) I appreciate your time. Yes I do have a specific implementation for iscsi and it is NOT a performance boost. I need the system to see remote disks as local disks… and this just so happens to be one of the features of iscsi. As far as I know the system can’t tell the difference between a local disk and a remote disk when you use iscsi…however that might need to be on the kernel level for that to work… i’m not sure.
I’m trying to implement lsyncd on an ubuntu machine to sync a remote drive with another remote drive. This is something that it wasn’t designed to do so I’m trying to use iscsi to mount the remote drives as local so the linux machine running lsyncd won’t be able to tell the difference. When lsyncd monitors two local drives it syncs files both ways automatically and both drives remain available to users. I’ve tried contacting the guys at google-code who made lsyncd but they haven’t responded yet. Anyways, any thoughts?
I would say then to try to cross-compile it. All the info you need is on the developer’s forum.
However, I think it is appropriate to put a disclaimer here. I’m not sure if this is a good idea in general. It may be that the iSCSI target for linux won’t play nice with the FS kernel, and thus lead to data loss. YMMV. Make sure to test it extensively before using this solution to any really important data.
Probably the biggest difference between NFS and iSCSI is NFS is a file-level protocol and iSCSI is a block-level protocol. This is why iSCSI makes disks appear as local disks - they obey the same SCSI semantics as a locally connected drive. For most home uses, NFS works fine, but if you were to run a database from it (for example) you’d really need iSCSI.
did anyone ever got iSCSI cross compiled / working on the Drobo FS?
Not yet, my attention has been deferred for now. All in all I’m just looking for a real time syncing option between multiple platforms(windows, linux)… any ideas?
I tried to compile it, but unless we get some help from DRI engineers I don’t think we’ll be able to do it.
Here’s the story so far: to make iSCSI work we need a kernel module. We can get the FS kernel source, and even compile the iSCSI module. The problem is that the module simply won’t load, throwing a “relocation out of range” error message. The closest I found on Google about it is this, which is a lot of talk and boils down to needing some specific kernel layout. Therefore, we depend on the willingness of DRI to help us out.
What do you mean by “real-time”?
I’m referring to an automatic transfer of new events in a monitored directory. This is different than a daemon checking every so often and comparing source and destination directories. One great tool that does this beautifully is lsyncd. It monitors a local directory using inotify and transfers triggered events using rsync by default. The problem with this is it’s still a one way sync. I need a two way auto sync on the block level. I don’t want to implement a huge system like DRDB either. Lsyncd will however, successfully monitor and sync two LOCAL directories with one another. So my idea is to monitor and sync a local directory with a remote directory via iSCSI so the local machine treats the remote directory as local… therefore allowing Lsyncd to monitor and sync BOTH WAYS to each directory because both directories appear to be local. I hope that makes sense. I just need this to work on a Drobo FS… which has no iSCSI support at the moment.
Ok, that’s what I thought you meant. I was going to mention all the stuff based on inotify, but since you are already aware of lsynd there isn’t much more to add.
Edit: it seems to me that lsyncd also works between remote folders. That should work, right?
Well, if you can install lsyncd on a droboFS:) I’m not sure if a droboFS even has inotify.
ok, thanks for the update.
I need iSCSI to run Windows Small Business Server Backups. The SBS Backup will only run on local drives (which iSCSI are for it). It would not have to be super fast, since the backup can run at night and as long as it does not block the whole network I don’t care if it is still running in the morning.
I was playing around with a HyperV VM on the SBS which would run iSCSI and mount an image from the Drobo FS. It worked fine, but SBS shuts down all Linux VMs, while Backup is running
iSCSI is one of the differentiators for the Drobo Pro FS, so perhaps from a marketing view they want to keep it that way.
Otherwise, I imagine it would be a software/firmware update.
yeah i know that they don’t have any motivation to get iSCSI running on the Drobo FS, so I had hoped someone had crosscomplied it without Drobos help.
It has. Lsyncd is very much feasible. I’m planning on cross-compiling it, but I’m under a bit of deadline at work right now.
OH boy:) That makes me excited! If you need any help let me know. I’ve never actually cross compiled anything but keep me up to date. My google-fu is pretty sharp so I could probably figure it out if I had the time… which is slim pickins’ nowadays.
I’m just going to leave this here: http://www.droboports.com/setting-up-a-vm