JSCSI是cleversafe中用的第三方的源代码,里面有很多类或包是没用的。
即使是cleversafe的源代码,有很多是其本身的一些试验性代码,在软件运行过程中是不起作用的。
另外,跨vault读写的工作和加入metadata的工作也不适合在scsi这一层来做,初步看应该在grid层以下。
首先,下面这个xml是很重要的,如果说cleversafe的代码不好读的话,这个文件是恶首之一。
dsnet-accesser/conf/core-org-bindings.xml
对远程多个slice服务器读写的实现是在
中
org.cleversafe.layer.slicestore.remote.RemoteSliceStore.readImpl(List<SliceName>)
实现的。
但是调用的话是在主要是在org.cleversafe.layer.grid.smartcontroller.ReadStateMachine中
其中的SliceNames,
是存在org.cleversafe.vault.BaseVault.sliceStores中的。
好了,有了这些,基本上就全部都能改了。
注 :SliceName的内容是什么,还不太清楚,可以整体编译后,运行log出来看看。以上仅是读代码后的猜测,具体还要log出来才知道是否正确。
另外,中间数据和mapping树之类的东西可以用java.io.RandomAccessFile来写到文件中。
#############################我是结束线#####################################
#############################我是结束线#####################################
#############################我是结束线#####################################
下面是跟着某人的思路看的,看就看了,也不删了.................
原始的jSCSI##################################################################
首先,在jSCSI大包里,读写最终是用:
org.jscsi.connection.Session.read(Object, ByteBuffer, int, long)
来实现的。
当jscsi相关模块收到的socket来的读写命令,交给session来处理的,
session本身是一个线程,通过:head = taskQueue.poll();来监视排列。
head.execute();
final Object thread = head.getCaller();
这里会判断是读或写,分别调用相应的模块 。
在这里 head的接口调用是关键:
对于读写来说head是一个 IOTask类,读写分别对应于ReadTask,WriteTask。
然后是一堆的继承和调用关系,最后现出原型:
org.jscsi.JSCSIDevice.read(long, byte[])
第一个是地址,二个是对应的内存块。读就是把地址中的数据读到后的内存块。
原始的jSCSI##################################################################完
如果还是原始的jSCSI的话:
再从头找回来,读的实现是在:
org.jscsi.connection.Session.ReadTask.execute()中的
phase.read(session, buffer, logicalBlockAddress, length);
又是一堆的继承和调用关系,
最后应该在:
org.jscsi.connection.FullFeaturePhase.read(Session, ByteBuffer, int, long)
但是在cleversafe的实现
ISCSITargetService 中的
LogicalUnit lu = new GridLogicalUnit(controller);
调用的是GridLogicalUnit(controller);
回过头来看一下:
Cleversafe JSCSI 实现解析
本文深入解析了Cleversafe中JSCSI的实现细节,特别是读写操作的具体流程,并探讨了cleversafe源代码中关键配置文件core-org-bindings.xml的作用及其与各组件间的联系。
226

被折叠的 条评论
为什么被折叠?



