EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Support for Concurrent i/o

Also by EldoS: Solid File System
A virtual file system that offers a feature-rich storage for application documents and data with built-in compression and encryption.
Posted: 12/08/2015 22:15:21
by Rod da Silva (Basic support level)
Joined: 12/08/2015
Posts: 4


I am new here and am evaluating CallBackDisk.

I have played with the MemDisk sample and it appears that all calls to the CallbackWrite() and CallbackRead() routines are serialized to the same thread.

For example I create and format an X: drive and then simultaneous read/write multiple files from multiple command lines to it.

Looking at the System.Diagnostic.Debug.WriteLine() output that I added to the callbacks I can see that all calls to the Callbacks are on a single thread and are therefore serialized (i.e.; a Read has to start and complete before a Write starts and completes).

In the case of an in memory Virtual Disk implementation there is no reason not to allow parallel access to non-overlapping block requests.

With care it is even possible to support overlapping i/o requests (for example if the memory resides on multiple machines over a network).

I want/need maximum parallelism and to be able to handle my own thread synchronization in my virtual disk implementation. I understand that if it is not done properly I could luck up the machine, but I want the rope to hang myself <smile>.

How can I configure CallBackDisk to give me more concurrency in my callbacks? As far as I can tell the current default severely limits performance of the Virtual Disk implementation.

Posted: 12/09/2015 04:35:47
by Volodymyr Zinin (Team)

Hello Rod,

Thank you for interesting of our product. You are right - CallbackDisk calls the OnRead and OnWrite callbacks sequentially. Actually there is only one worker thread which calls the callbacks. It was done so in order to prevent situations when there are several read and write operations for the same disk sectors and they overrun each other. For example it should be a write operation to a sector first and then read, but because of parallel calling of the OnRead and OnWrite callbacks it can occur that the OnRead callback will be called earlier than the OnWrite callback, which causes the incorrect data will be returned from the OnRead callback.
Posted: 12/09/2015 08:53:53
by Eugene Mayevski (Team)

To add to Volodymyr's answer - it's possible for us to extend CallbackDisk to get parallel operations, however, this is a significant piece of work (we'd need to track overlapping operations and put them to the queue), so we would be able to do it only after proper compensation.

Sincerely yours
Eugene Mayevski
Posted: 12/09/2015 10:01:02
by Rod da Silva (Basic support level)
Joined: 12/08/2015
Posts: 4

Volodymyr, Eugene,

Thank-you for your prompt response.

I understand the problem of the lost update. However, to serialize the i/o the way you are currently doing it in CallBackDisk is to make major assumptions about how the Virtual Disk will be implemented. It is to assume for example that the "device" has only one logical "head" for reading and writing. A RamDisk or Network Block storage array implementation will not have this restriction. They are well suited for parallelism but I can't get there if your driver is unnecessarily restricting concurrency.

Eugene, you mentioned adding this support to CallbackDisk is a significant piece of work because you would need to track overlapping operations and put them to the queue. Why can't you just forward the requests in parallel "as is" and let the Virtual Disk implementation sort it out? Every request has an offset and a length which means the CallbackRead() and CallbackWrite() routines have the information they needs to figure out if the calls are overlapping and lock accordingly.

Regarding the "lost update problem" mentioned earlier, there are even clever ways to handle/optimize this issue as well. For example, it is really only of concern for "implicitly shared" virtual disk sectors such as those that are part of the File System Index/meta data proper. Note that i/o requests associated with actual end user "file data" is NOT usually accessed for WRITE purposes in a parallel. That is,most apps open files for writing exclusively. And in the case of the FS metadata, this data is written to my knowledge primarily to the beginning of the virtual disk and a little at the end of the virtual disk. Some heuristics could then be developed to serialize reads/writes to those areas and allow parallel non-overlapping read/writes to all other areas. Worst case scenario would be to serialize all writes while allowing reads in parallel (i.e.; classic reader/writer) locks. This would still represent a major performance increase for the virtual disk implementation for heavy read utilization scenarios.

My point is if there are no technical reasons not to, why not give the responsibility of the thread management to the Virtual Disk implementation where I argue it belongs? After all that is where it would be if this Virtual Implementation CallbackRead/Write() code was in the Kernel mode driver itself rather than in user-mode callbacks.

As it is right now, while I appreciate the safety your current implementation provides, it is a showstopper for me. I need the power to manage my own thread/management and am willing to bear the responsibility of it.

I would like to propose that you compile a special version of your driver for me to test for you, with the follow 2 small changes - make the i/o Queue Dispatch Type of your driver "Parallel" instead of the Sequential and let the Device object also support parallel requests. With these small changes, and assuming I manage the overlapping case with proper locking in my callbacks, I should be able to drastically speed up my Virtual Disk implementation (by an order of magnitude under heavy load I would guess) by servicing non-overlapping i/o to happen in parallel - all with no other changes on your end.

In return I can promise you 2 things: 1) I have the perfect application in mind to test this new version of driver thoroughly for you, and 2) if it in fact works I will purchase a license to the product.

Let me know what you think.

Posted: 12/09/2015 10:17:07
by Eugene Mayevski (Team)

I appreciate your feedback on the topic very much. Still, we can not invest time into this functionality at the moment, especially on "if you implement, I will buy". As said, extending existing functionality is technically possible, but only after the compensation. I understand that you need this functionality to use the product, yet we need to consider other factors as well. We have plenty of important work to do, and we need to choose carefully, in which functions of which products we should invest most of our internal resources (which are not unlimited).

Sincerely yours
Eugene Mayevski
Posted: 12/09/2015 11:24:14
by Rod da Silva (Basic support level)
Joined: 12/08/2015
Posts: 4


I have no problem paying for a solution that meets my needs. Can we meet (online) to discuss an arrangement that will work for us both? Please email me privately and I can set up a GoTo Meeting to discuss.

Posted: 12/09/2015 11:29:28
by Eugene Mayevski (Team)

You can reach me using the Live Chat, when it's online. I will be available there in 3 hours.

Sincerely yours
Eugene Mayevski
Also by EldoS: Callback File System
Create virtual file systems and disks, expose and manage remote data as if they were files on the local disk.



Topic viewed 7897 times

Number of guests: 1, registered members: 0, in total hidden: 0


Back to top

As of July 15, 2016 EldoS business operates as a division of /n software, inc. For more information, please read the announcement.

Got it!