EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Drive mount flow

Also by EldoS: CallbackProcess
A component to control process creation and termination in Windows and .NET applications.
#5136
Posted: 02/22/2008 10:42:39
by Fernando Nunes (Basic support level)
Joined: 11/30/2007
Posts: 6

We're using your Callback FS Driver for both 32 and 64 bits with C# 2.0.

It's working smoothly on Windows XP and 2003, however we're running into some issues when we install the driver then try to mount the drive and (simultaneously) the user is trying to open My Computer.

Most of the time it freezes the Explorer Window and then doesn't creates the volume correctly making it unusable.
Then when we close our program and execute UnmountMedia with the force parameter set to true, it doesn't removes it from system, only at next reboot.

What I'm looking for is some insight on the (driver installation / volume mount / mounting point) creation process and its interaction with the initialization CbFs callbacks (like CbFsMount, CbFsOpenVolume and CbFsGetVolumeSize).
Also, what timeouts and force options are better, if that is the case.

Best regards,
Fernando Nunes
#5153
Posted: 02/23/2008 09:39:26
by Volodymyr Zinin (EldoS Corp.)

Hello,

Quote
Fernando Nunes wrote:
It's working smoothly on Windows XP and 2003, however we're running into some issues when we install the driver then try to mount the drive and (simultaneously) the user is trying to open My Computer.

Most of the time it freezes the Explorer Window and then doesn't creates the volume correctly making it unusable. Then when we close our program and execute UnmountMedia with the force parameter set to true, it doesn't removes it from system, only at next reboot.

Unfortunately we can't reproduce this problem. Could you specify in details how to reproduce it?

Quote
Fernando Nunes wrote:
What I'm looking for is some insight on the (driver installation / volume mount / mounting point) creation process and its interaction with the initialization CbFs callbacks (like CbFsMount, CbFsOpenVolume and CbFsGetVolumeSize). Also, what timeouts and force options are better, if that is the case.

The internal mechanism of CallbackFS is quite similar to other standard file systems (FATFS, NTFS). It "simply" passes file system specific requests (that are sent by operating system to the CallbackFS file system driver) to the user mode callbacks. You can find information about these requests and how Windows file systems work in Microsoft's DDK.
Timeouts values are specific to a file system which is implemented by the use of the CallbackFS product. For example the file system can use long-term network operations, so by setting appropriate timeouts you can prevent your storages from freezing.
#5172
Posted: 02/26/2008 11:23:39
by Fernando Nunes (Basic support level)
Joined: 11/30/2007
Posts: 6

I'm having this problem specially after a fresh driver installation.
Well.. to reproduce the problem try doing something like:

1) Install the driver. Imediatly after success, invoke another program that does:
CreateStorage, MountMedia, AddMountingPoint
On the CbFsGetVolumeSize and CbFsOpenFile make them invoke a webservice, if possible !

2) At the same time, go to "My Computer"... and see how it behaves.
#5173
Posted: 02/26/2008 11:40:03
by Eugene Mayevski (EldoS Corp.)

I am sorry but this is not a meaningful report.

There's a limited set of operations that are allowed in callbacks. Doing many things can cause a deadlock. So you must be *very* careful about what you are doing in callbacks. Ideally, in callbacks you should only read/write local information from/to memory, leaving network and disk operations for other thread, which works in background.



Sincerely yours
Eugene Mayevski
#5174
Posted: 02/26/2008 11:55:05
by Eugene Mayevski (EldoS Corp.)

Also it can be that there's no deadlock, but Explorer is waiting for return from callback. Are callbacks executed to the end, or they are also blocked in the middle?


Sincerely yours
Eugene Mayevski
#5175
Posted: 02/26/2008 12:23:50
by Brad O'Hearne (Standard support level)
Joined: 03/16/2007
Posts: 12

Eugene,

I don't mean to jump into your conversation here, but there was something you said that I hadn't heard before which is of great material importance to Callback FS development in general, and I wondered if you might expound further on it. I posted here because I thought it would be of general benefit to the entire community, but if you would like to take it to a private support ticket that is fine too.

Quote
Doing many things can cause a deadlock. So you must be *very* careful about what you are doing in callbacks. Ideally, in callbacks you should only read/write local information from/to memory, leaving network and disk operations for other thread, which works in background.


I'd like to know about a couple things:

1) Since Callback FS by default is synchronizing callbacks on a specific file, I'd like to know some of the use cases (if there are many) that can cause a deadlock. Can you give a few examples?

2) What is the essential problem with doing network and disk operations in callbacks? The potential problem that I see arising from sending disk operations to another thread is that the callback will complete, leaving the caller expecting that the operation has been completed, and the caller may invoke another callback as a result, but meanwhile, the secondary thread which the first disk operation has been handed to hasn't yet completed. I'm curious as to the exact nature of the problem with a disk operation in a callback, because the nature of the callbacks themselves suggest a completion of one callback before the execution of another.

I look forward to your reply.

Brad

#5176
Posted: 02/26/2008 12:42:51
by Eugene Mayevski (EldoS Corp.)

Quote
brado77 wrote:
1) Since Callback FS by default is synchronizing callbacks on a specific file, I'd like to know some of the use cases (if there are many) that can cause a deadlock. Can you give a few examples?


Some badly written file system filter-based application (antivirus, audit tool etc.) can cause the deadlock if it accesses the disks as a consequence of your callback operation. We came across AVG antivirus (some older version) which did this and we had to add a workaround for that particular class of bugs. But who knows, how many other applications have similar bugs.

Next, Windows GUI must not be used from callbacks as this is a straight way to the deadlock.

Network operations are usually safe, but if the OP talks about web services, there's likely some framework to be involved, and who knows what this framework does.

In general, everything depends on the usage scenario. The approach that will work in one application can fail in another application due to seemingly minor difference.


Sincerely yours
Eugene Mayevski
#5177
Posted: 02/26/2008 12:57:52
by Brad O'Hearne (Standard support level)
Joined: 03/16/2007
Posts: 12

Eugene,

Can you additionally give an example of where writing to disk in a callback would cause a deadlock?

Thanks,

Brad
#5178
Posted: 02/26/2008 13:20:15
by Eugene Mayevski (EldoS Corp.)

in the case mentioned above for antivirus or audit software.


Sincerely yours
Eugene Mayevski
#5183
Posted: 02/27/2008 02:21:00
by Eugene Mayevski (EldoS Corp.)

I forgot to mention one more thing regarding deadlocks:

http://www.eldos.com/documentation/cb...cache.html

If you don't set the value correctly, deadlock in Windows Cache Manager can happen.


Sincerely yours
Eugene Mayevski
Also by EldoS: Rethync
The cross-platform framework that simplifies synchronizing data between mobile and desktop applications and servers and cloud storages

Reply

Statistics

Topic viewed 10920 times

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




|

Back to top

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

Got it!