Since the SATA release is imminent, and presuming we are going on the 2.6 kernel, and there are some great ideas surfacing here in the feature request areas again  , here is my 2c:

 

SAN support, namely implementation of an open source iSCSI target for the UnRaid.

 

For those not familiar with NAS vs SAN, there are two  pertanent factors: 1. both Client and server need iSCSI software that will make the SAN look like another mounted drive on the client, 2. potentially massive  throughput improvement on NAS protocols like SAMBA and even NFS. Not sure it could be combined with jumbo Frames, if it can then it would be a huge boost in throughput. Of course, throughput is just one piece of the UnRaid performance puzzle.

 

ref.

 

http://www.ardistech.com/iscsi/

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

http://www.cuddletech.com/articles/iscsi/index.html

http://www.cs.uml.edu/~mbrown/iSCSI/

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

 

Having said all that, I think Joe's NTFS feature and rharvey's list of needed fixes should take precedence.

 

Tom,

 

Maybe you should  solicit an absolute list of wanted features from us (and on AVS F), and then have a forum(s) vote for top 5?

 

 

Since the SATA release is imminent, and presuming we are going on the 2.6 kernel, and there are some great ideas surfacing here in the feature request areas again  , here is my 2c:

 

SAN support, namely implementation of an open source iSCSI target for the UnRaid.

 

For those not familiar with NAS vs SAN, there are two  pertanent factors: 1. both Client and server need iSCSI software that will make the SAN look like another mounted drive on the client, 2. potentially massive  throughput improvement on NAS protocols like SAMBA and even NFS. Not sure it could be combined with jumbo Frames, if it can then it would be a huge boost in throughput. Of course, throughput is just one piece of the UnRaid performance puzzle.

 

ref.

 

http://www.ardistech.com/iscsi/

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

http://www.cuddletech.com/articles/iscsi/index.html

http://www.cs.uml.edu/~mbrown/iSCSI/

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

 

Having said all that, I think Joe's NTFS feature and rharvey's list of needed fixes should take precedence.

 

Tom,

 

Maybe you should  solicit an absolute list of wanted features from us (and on AVS F), and then have a forum(s) vote for top 5?

 

 

 

Yes, we are considering adding iSCSI support, as well as possibly AOE support.  Note that both these protocols are block-level, which means that all data drives will appear as separate physical disks.  They would show up in windows as individual "hard drives", e.g, D:\, E:\, F:\, G:\, etc.  There are advantages and disadvantages with this approach.  The main reason we haven't offered this yet is because of the lack of open source target code.

Tom,

 

per,

 

  The main reason we haven't offered this yet is because of the lack of open source target code.

 

What about these projects:

 

http://iscsitarget.sourceforge.net/

 

http://sourceforge.net/projects/unh-iscsi

 

http://sourceforge.net/projects/linux-iscsi (based on old cisco code) or it's replacement on the new kernel,

 

core iscsi: http://www.kernel.org/pub/linux/utils/storage/iscsi/

 

http://sourceforge.net/projects/iscsi or

 

http://www.open-iscsi.org/

 

I'm also impressed by Openfiler, which is a nice hybrid SAN/NAS interface/os, basically supports every protocol under the sun, and has an iSCSI target/initiator in the OS (presumably based on one of the above projects or home grown code).

 

It's all open source AFAIK.

 

BTW, I think iSCSI is much more useful than both AoE and HyperSCSI, simply because the former is routable, given it's IP based,  compared to the latter two low level ethernet drivers, I think they  more accurately resemble a fibre channel operation, aka less overhead but more headaches  .

 

-Alex

 

 

 

Thanks for the links - when I get some I look into this again.  I'm familiar with some of these projects.  As I recall, they all had some kind of deficiency as a pure target.  For example, one of them included target support, but only skeleton - enough to provide something to check out initiator support.  Another only supported the 2.6 kernel.  So... again thanks for the research and links.

Thanks for the links - when I get some I look into this again.  I'm familiar with some of these projects.  As I recall, they all had some kind of deficiency as a pure target.  For example, one of them included target support, but only skeleton - enough to provide something to check out initiator support.  Another only supported the 2.6 kernel.  So... again thanks for the research and links.

 

Tom,

 

You may be best rewarded at looking at Openfiler as the most complete implementation. But there may be a lot of code parsing  to find it.

 

http://sourceforge.net/project/showfiles.php?group_id=90725

 

 

Ping, any update on this? Would be great, thanks!