[ANN] STARWIND AND STARPORT iSCSI SOFTWARE SOLUTIONS WILL BE DISTRIBUTED ON FREE FOR NON COMMERCIAL USE BASIS.
Anton Kolomyeytsev
Rocket Division Software [in...@rocketdivision.com]
STARWIND AND STARPORT iSCSI SOFTWARE SOLUTIONS WILL BE DISTRIBUTED ON
FREE FOR NON COMMERCIAL USE BASIS.
Rocket Division Software has announced its leading iSCSI solutions
StarWind (iSCSI target) and StarPort (iSCSI initiator) will be
distributed on a FREE FOR NON COMMERCIAL USE basis.
"It was a kind of difficult decision to distribute the products this
way," Anton Kolomyeytsev, the CEO says, "after all the main goal of
the business is to bring the financial success to its founders,
investors and employees and the solutions on this market are not cheap
in general. However we believe that this decision will be very much
appreciated by our potential customers and besides will popularize the
iSCSI technologies. I think some day it will pay back and of course
the commercial use of our software is possible only for money."
StarWind is an iSCSI target (server-side) product. This software
combined with StarPort iSCSI initiator (or any iSCSI initiator iSCSI
1.0 compatible) running on client allows you to export any local CD
and DVD burners to the network users (all CD and DVD recording
applications running on a client side are supported), export local
tape drives for backup and restore on client machine (all of the
backup software tools running on a client machine are supported),
virtual hard disk drives over the network, export whole server storage
subsystem over the network at the block level, work with the dynamic
volume snapshots, incremental backups and virtual tapes etc. Create
RAM disk drives for temporary data storing (Solid-State-Disk
emulation). Export standard CDI, ISO and MDS images as network virtual
CD and DVD drives. More information can be found at
http://www.rocketdivision.com/wind.html
StarPort is an iSCSI initiator (client) product. This software
combined with StarWind iSCSI target running on server (or any iSCSI
target confirming iSCSI 1.0 standard can be used) allows you to burn
to remote CD and DVD burners over the network (all CD and DVD
recording applications are supported), backup and restore to remote
tape drives (all of the backup software tools are supported), work
with remote virtual hard disk drives over the network, backup whole
server storage subsystem over the network, work with the dynamic
volume snapshots, incremental backups and virtual tapes etc. Create
RAM disk drives for temporary data storing. Mount standard CDI, ISO
and MDS images as virtual CD and DVD drives. More information can be
found at http://www.rocketdivision.com/port.html
About Rocket Division Software: Rocket Division Software is rapidly
growing company providing cutting-edge system-software solutions for
Windows NT/2000/XP/2003 and various UNIXes. We're positioning as a
provider of the top-notch, high-performance technologies for the data
storage and networking industry. Our "know how" and development
services cover a wide range of existing and emerging storage and
networking technologies, such as: CD/DVD recording and mastering,
iSCSI virtual storage, local and network file system design. Rocket
Division Software can be contacted at
http://www.rocketdivision.com/
Rocket Division Software
Winey
The announcement below _implies_ support for IDE and ATAPI interfaces
(or is very poorly written) as well as SCSI, but there seems to be no
discussion, even in the FAQ, about specific drive interfaces
However, IETF RFC 3720, which defines iSCSI, states that iSCSI is a
way to carry standard SCSI protocol data units over IP. This is the
Abstract of RFC 3720:
Abstract
This document describes a transport protocol for Internet Small
Computer Systems Interface (iSCSI) that works on top of TCP. The
iSCSI protocol aims to be fully compliant with the standardized
SCSI
architecture model.
SCSI is a popular family of protocols that enable systems to
communicate with I/O devices, especially storage devices. SCSI
protocols are request/response application protocols with a common
standardized architecture model and basic command set, as well as
standardized command sets for different device classes (disks,
tapes,
media-changers etc.).
As system interconnects move from the classical bus structure to a
network structure, SCSI has to be mapped to network transport
protocols. IP networks now meet the performance requirements of
fast
system interconnects and as such are good candidates to "carry"
SCSI.
The full RFC can be found at: http://www.ietf.org/rfc/rfc3720.txt.
--W--
On 16 Sep 2004 01:10:12 -0700, is...@rocketdivision.com (Anton
Anton Kolomyeytsev
traffic to the device AS IS (virtualization layer most of the other
iSCSI target software add w/o not even asking you is simply missing).
See, all modern OSes have storage stack designed with SCSI in mind. So
native SCSI commands would be translated to protocol-dependent bytes
only at the storage controller driver. Below (up to the top of the
storage stack) device would appear to be SCSI one. So do not try to
find the problems in the place they do not exist ))
Regards,
Anton Kolomyeytsev
CEO, Rocket Division Software
Winey <NOSP...@no-one-here.com> wrote in message news:<b0lkk05bnnbtkgn06...@4ax.com>...
Winey
Kolomyeytsev) wrote:
>StarWind can be used as iSCSI <-> PATA/SATA bridge. Delivering SCSI
>traffic to the device AS IS (virtualization layer most of the other
>iSCSI target software add w/o not even asking you is simply missing).
>See, all modern OSes have storage stack designed with SCSI in mind. So
>native SCSI commands would be translated to protocol-dependent bytes
>only at the storage controller driver. Below (up to the top of the
>storage stack) device would appear to be SCSI one. So do not try to
>find the problems in the place they do not exist ))
>
Anton,
Thank you.
With all due respect, I used to work for a disk drive company. In
general, there is no way on a single platform to make non-SCSI devices
appear to be SCSI except through the use of a bridge card.
I read a good part of RFC 3720, and it makes no mention of non-SCSI
protocol stacks (which would be outside of its purview, but might be
mentioned anyway because of the importance of this issue.)
Given that what you have said above is true, it would be very useful
to cover all these issues in sufficient detail on your company's web
site.
I am not trying to find problems that "don't exist." I can guarantee
you with 100% certainty that every IT manager worth his salt will have
the same questions in mind. IT managers have had too many "miracle"
products come their way, which later turned out not to be able to
deliver their claimed benefits.
Some good technical information, perhaps a White Paper, would go a
long way to eliminating these doubts.
--W--
Rob Turk
> On 17 Sep 2004 13:28:09 -0700, an...@rocketdivision.com (Anton
> Kolomyeytsev) wrote:
>
>>StarWind can be used as iSCSI <-> PATA/SATA bridge. Delivering SCSI
>>traffic to the device AS IS (virtualization layer most of the other
>>iSCSI target software add w/o not even asking you is simply missing).
>>See, all modern OSes have storage stack designed with SCSI in mind. So
>>native SCSI commands would be translated to protocol-dependent bytes
>>only at the storage controller driver. Below (up to the top of the
>>storage stack) device would appear to be SCSI one. So do not try to
>>find the problems in the place they do not exist ))
>>
>
> Anton,
>
> Thank you.
>
> With all due respect, I used to work for a disk drive company. In
> general, there is no way on a single platform to make non-SCSI devices
> appear to be SCSI except through the use of a bridge card.
>
Several operating systems offer SCSI-like interfaces to non-SCSI devices. On
Windows you can address almost all storage devices through SPTI, regardless
if they are SATA/PATA, SCSI, Fibre, USB or Firewire attached. Linux offers
an IDE-SCSI layer that can expose IDE disks, CD/DVD and tape devices as
SCSI.
As long as the command sets mimic SCSI it doesn't really matter what the
transport is.
Rob
Anton Kolomyeytsev
protocol dependent stuff (ATA/ATAPI in our case). Either SCSI-line
driver would take care of this (so "wrapping" code would be executed
on host CPU) or dedicated processor on ATA<->SCSI card would run the
"wrapping" code. Result is identical.
Regards,
Anton Kolomyeytsev
CEO, Rocket Division Software
Winey <NOSP...@no-one-here.com> wrote in message news:<06cnk0daa5q4rjlju...@4ax.com>...