Open SCSI, making more legends or jokes!

2009年6月15日 17:51 Digi Ponta | 個別ページ | トラックバック(0)

Subject: Open SCSI, making more legends or jokes!

- SCSI spirits excited by a SCSI specification enhanced with any idea, and the unexpected SCSI/storage features! -

Date: Sat, 13 Jun 2009
ATTN: SCSI Fun/Yankee, ANSI/T11 and OS/Middleware developers, and my friends

Dears,

Now, I am one of SCSI fun, and have been bored very much, about the current SCSI (Small Computer System Interface) specification by ANSI/T11. And then, I feel the pure SCSI needs any more feature to be enhanced, for able to be excited by the SCSI specification, any more. Someone wants any more complexity than the too simple feature of the current specification. Of course, I know iSCSI (Internet SCSI) challenging another physical media of IP by IETF/RFC. While, I can find the unique challenges to conventional technologies, as CEE (Converged Enhanced Ether-network) by IEEE. So, I would like to the unique proposal for enhancing the pure SCSI specification, however for practical use cases. And, I should think normal use cases, but I need unique solutions for them for being excited by them. Then, of course, I know to need new technology for the enhancements, also, and that today’s storages had already had some new feature compared with ancient one. I would like to think any offload to SCSI storage, for OS (Operating System), DBMS (Database Management System) and OLTP (Online Transaction Process) system executed on Server/PC and any available technology.

Well, I have two ideas as use cases of offloads for them. My first idea is the offload of a file system (FS) built-in OS. The second is one of transaction monitor with DBMS and/or OLTP system. I think enhanced SCSI should be able to handle the below two case of the offloads. Of course, I believe there are many useful cases except mines in the world. Basically, mines are samples, so that I hope you and SCSI fun will propose your ideas and will have the implementations in future.

(Case 1) “offload of file system” with a thin provisioning feature for a LU:

This enhanced SCSI layer can have managed a space for a file with thin provisioning feature, for example, the enhanced FS will save each a file to each a LU (Logical Unit). So, the FS handle a LU as a file. For the implementation, I think some ideas for the enhancing SCSI. By one idea, with the enhanced SCSI, for example, LUN (Logical Unit Number) may have an integer with a bigger size than or an equal size to 64bit. By another idea, LBA (Logical Block Address) may have an integer with a bigger size than or an equal size to 128bit. By this, we can use the upper field as a file id, and lower field as a byte offset and legacy. By the last one, I may use a seek command for specifying a file. Of course, I know to need to specify any more details for the above ideas, and enhance a file system built-in OS. Now, I feel success for anyone to have inspiration by my hints for the enhanced SCSI, so that engineers can be excited about enhanced SCSI. So that, this case seems to unify memory area of volume and file by LU, then we may handle files and LUs only by operation feature for LU.

(Case 2) “offload of transaction monitor” with a disk write-back cache memory feature:

In my second idea, this enhanced SCSI layer may be able to undo data updated by sequence of write commands for a transaction on DBMS and/or OLTP system. By this enhancement, storage may be able to undo the update, when DBMS and/or OLTP system have miss-written data to LBAs except ones that they expects, with losing their control, without making a commitment for the transaction. If a storage device can’t undo it, the systems need a recovery with DB area backup and journal data, in this case. So, I feel a little merit for this offload, also. Well, I think, for example, that this implementation may use tagged I/O command. The tag ID may have an integer with a enough bigger size than the current specification, if needing it. The system may relate and manage a transaction to a tag ID temporally, until a commit/done or roll-back/undo of the transaction.

However, you must feel un-success and fatigue, many ancient trials of accelerations for data processing and retrieval, while a SCSI command set has already had data-processing functions for a compare, a copy, a retrieval and on so. I think so, too. Then, I don’t propose any idea for them, in this proposal. If I feel it good, I must put the third case of offload for data processing. Now, I think there is a much greater merit for offloads of data/resource management than data processing. And, that we have missed to know the merit, because ancient computer engineers had escaped from a very little complex for today’s engineers, maybe. For example, as my additional idea, storage may presents some kind of special-use devices as a huge-size pipe device (FIFO or LIFO) used and offered by an OS. Maybe, SCSI command set will need any more additional feature for the implementations and handling them. Then, I feel that it may be useful for streaming computation.
So, I feel good that SCSI world (as a representative of hardware world) has a little of innovation and breakthrough into new style and SCSI/storage life exciting the fun, and supports the current age of a vertical Integration style and IT industry. At last, can SCSI fun enjoy an enhanced SCSI specification or not, in near future? I hope SCSI fun can feel frank and enjoy this proposal.

Best Regards and thank you,
One of SCSI fun

以上、知人からのメッセージでした。いかがでしたでしょうか？　こんな時代もあったと、黄昏てしまう私です。