SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: Part II (Re: question on iSCSI and NBD)



    >     MUST be possible to build I/O adapters that handle the entire SCSI 
    > task.
    
    There has been a lot of fluff around this subject. The fact is that NBD is a
    block protocol and SCSI (which iSCSI represents) is not.
    
    Eddy
    
    -----Original Message-----
    From: Andre Hedrick [mailto:andre@linux-ide.org] 
    Sent: Saturday, April 12, 2003 1:22 AM
    To: sunzen.w
    Cc: ips@ece.cmu.edu
    Subject: Re: Part II (Re: question on iSCSI and NBD)
    
    
    Hi Sunzen,
    
    All iSCSI is the command and data transport wrappered in TCP traffic.
    This has to play by normal rules of classic HOST-DEVICE IO.
    Thus the ECC and CRC's which are hidden in the hardware and passed over
    the parallel or fibre cable must to exposed and handled.
    
    If one does not have a strong understanding of the basic HOST-DEVICE
    transport for both sides of their respective state machines, one will not
    be able to extract, recreate the applied, and expected transports.
    
    On 11 Apr 2003, sunzen.w wrote:
    
    > In RFC 3347, section 2  Summary of Requirements,it says:
    >
    >     MUST be possible to build I/O adapters that handle the entire SCSI
    > task.
    >
    
    Since NBD fails to support the fundamental basics of the HOST-DEVICE, it
    can never be exepected to mature to support the basic HOST-DEVICE
    transport, much less the extended/customized task management core of
    operations in todays SAN Management.
    
    When one can address/document the expected ("REQUIRED") behavior of both
    sides of the 'state diagrams' for the effective HOST-DEVICE pair in a NBD
    environment, it will then begin to take the first steps to mature.
    However, NBD will always fail.  NBD as no need or capabilities to handle
    "non-data" operation commands.  The very best one could do is to pass the
    operation to the DEVICE(effective) and then convert it the locate
    T10,T11,T13 NCITS transport.  So now that one has come full circle on the
    reasons why NBD will always fail to achieve mature status, one should see
    NBD is cute, fun, interesting for the second year undergraduate, period.
    
    Cheers,
    
    Andre Hedrick
    LAD Storage Consulting Group
    http://www.pyxtechnologies.com/
    
    On 11 Apr 2003, sunzen.w wrote:
    
    > Thank you,Andre Hedrick.
    > 
    > >From your last two emails, i get nearer to see the power of standard.
    > I admit it, and i am willing to be with standard.
    > 
    > But one thing is still confronting me.
    > 
    > As to my understanding,iSCSI is a more lower,and hence more special
    > protocol.It is for the reason of compatibility with the traditional
    > technology.But this will maybe give performance loss when using it to
    > access the virtual devices(It is just from a glance at the path it
    > walks),and also the path it walks, which is it goes down to the level of
    > SCSI command at the initiator side,and at the target side goes up again
    > to access the virtual devices, doesn't seem good and smart.Maybe a more
    > neutral and upper protocol would be helpful to that.
    >   
    > In RFC 3347, section 2  Summary of Requirements,it says:
    > 
    >     MUST be possible to build I/O adapters that handle the entire SCSI
    > task.  
    > 
    > I am not clear for it's concrete meaning. is it helpful?
    >  
    >      
    > 
    >  
    > 
    > 
    > -----original message----------
    > > 
    > > Hi Sunzen,
    > > 
    > > I did not address the other points ypu put forward in the previous
    reply.
    > > 
    > > One of the key issues nobody wants to address, everything about storage
    is
    > > a lie.  iSCSI does a fantastic job of doing it bold and in your face.
    > > Now, what do I mean by stating "Everything about Storage is a Lie"?
    > > 
    > > Given when a host talks to device, the device tells the host what it
    wants
    > > the host to know about itself and not everything is disclosed.  This is
    > > similar to the usage of virtual devices like LVM, RAID, or any other
    > > non-scsi spindle/media.  iSCSI is perfect for keying the storefornt of
    > > storage in the same information path, and it even does it better than in
    > > the past.
    > > 
    > > Now any quality version of iSCSI targets in the market space will be
    able
    > > to mimic or lie about its physical spindle, and report it as a SCSI
    > > device.  This somewhat follows the history of MicroSoft's MiniPort(tm)
    > > API or in the BSD's aka CAM.  Believe it or not the miniport is slicker
    > > and smoother than CAM.
    > > 
    > > So when one exploits the virtual devices and converts their appearance
    and
    > > behavior to a scsi-like device, one also gains the ability to use the
    > > known and trusted management suites.  I do not use or hold any trust in
    > > their features, but my customers and others do.
    > > 
    > > Lastly iSCSI has to power to democratize storage and strip away from the
    > > giant sloaths, who tightly control FC and fail at the interoperability
    > > test, to empower the customers of today bound in the chains of FC.
    While
    > > the greatest market space is for the 95% of the ignored customer base
    who
    > > can not or refuse to pay the excessive costs of FC.  Key point is that
    an
    > > emerging technology does not replace an existing one out of the box;
    > > however, it does provide a way and an out for todays customers of
    > > enterprise and future customers who want cost effective enterprise.
    > > 
    > > Given storage is a customer driven marketspace, NBD has no customers.
    > > 
    > > The only other item left is the 5 paradigm shift in the economy which
    will
    > > accelerate the adoption and migration to iSCSI, but that is another
    email
    > > offline for you to enjoy later.
    > > 
    > > Cheers,
    > > 
    > > Andre Hedrick
    > > LAD Storage Consulting Group
    > > http://www.pyxtechnologies.com/
    > > 
    > > All trademarks belong to their respective companies.
    > > 
    > > On 10 Apr 2003, sunzen.w wrote:
    > > 
    > > > I have a question on iSCSI.It is originated from contrast of iSCSI
    with
    > > > NBD.
    > > > 
    > > > As all know, NBD also support block storage over IP. So maybe we can
    > > > also consider it as a technology of IP storage,which originated even
    > > > earlier than iSCSI.
    > > > 
    > > > Besides it's simplicity (which may bring less powfulness. ?)
    > > > Another feature i think more is that it intercepts on the request
    level.
    > > > while iSCSI intercepts on more lower level,it is on SCSI command
    level.
    > > > This shows a different computing distribution strategy.
    > > > 
    > > > But with the prevalence of virtual device(such as LVM ,...)
    > > > what are the results of the two different technology?
    > > > In order to access the virtual device, the low level request of SCSI
    > > > command which are carried by iSCSI should be transformed to upper
    level
    > > > request,while the additional transformation is not needed when using
    > > > NBD,where just a simple routing mechanism is needed. 
    > > > 
    > > > Do i understand them correctly?
    > > > As a technology of IP storage ,iSCSI provide apparent advantages(not
    all
    > > > the aspects) over FCP 
    > > > What advantages over NBD does iSCSI provide?  
    > > > 
    > > > need all your point and help.
    > > > 
    > > > with my best regards. 
    > > > 
    > > > 
    > > > 
    > > > 
    > > 
    > > 
    > 
    > 
    
    


Home

Last updated: Tue Apr 15 02:19:37 2003
12494 messages in chronological order