EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Performance issue when writing multiple files to cbfs drive

Posted: 04/21/2015 06:50:45
by William Levra-Juillet (Priority Standard support level)
Joined: 09/05/2013
Posts: 49

I'm investigating poor performance issue, when copying multiple files to a cbfs drive.

We are using:
- SerializeCallbacks FALSE
- Min and max worker threads to zero (default) on a 8 core i7 win8.1 pc.
- ParalleledProcessingAllowed TRUE
- CBFS_SYMLINK_SIMPLE, mounted as X:
- We expose network devices (as folders) in the root X:

How to repro:
- From Explorer, drag&drop a large file1 to x:\device1\file1
- From Explorer, drag&drop a large file2 to x:\device2\file2

We are expecting the "WriteFile" callbacks to be sent and processed simultaneously, but they are not :(

We receive, in sequence, a few requests to write 1MB of data to file1 (device1), and only after that a few requests to write 1MB of data to file2 (device2), then file1, then file2, etc...
file1 and file2 are never copied in parallel :(
But that was the case when we were using Dokan (we switched from Dokan to cbfs)

- To copy a single file, cbfs is slightly faster than dokan (~5%)
- But to copy N files, cbfs is ~N times slower than Dokan :(

This is a blocking issue for us.
Any suggestion?
We'd really appreciate your cooperation to solve this problem.

Thank you very much
Posted: 04/21/2015 06:58:50
by Eugene Mayevski (Team)

It's interthread synchronization and this is where Dokan could crash badly due to lack of proper synchronization.

Please try to enable and disable file cache and see if this change the behavior (it should).

Sincerely yours
Eugene Mayevski
Posted: 04/21/2015 08:40:00
by William Levra-Juillet (Priority Standard support level)
Joined: 09/05/2013
Posts: 49

Thx Eugene,

I've changed FileCacheEnabled from FALSE to TRUE. Same problem.
I understand interthread synchronization, but that doesn't explain why all the write requests (to different files) are serialized. That defeats multithreading completely.

Any other suggestion on how to solve the problem?
If that's a limitation in cbfs code, could you see what can be done to fix that?

Thank you
Posted: 04/21/2015 09:28:22
by Eugene Mayevski (Team)

So far I am mostly guessing. Does the problem expose itself on unmodified Mapper sample?

Sincerely yours
Eugene Mayevski
Posted: 04/21/2015 10:56:39
by William Levra-Juillet (Priority Standard support level)
Joined: 09/05/2013
Posts: 49

Thx for the Mapper sample suggestion.
Interestingly, it doesn't expose the problem.

So, I spent a few hours trying to find the setting that causes my problem.
And I found the culprit!
It's StorageCharacteristics (default to RemovableMedia), but set to 0 in our code (local disk).

How come a value of 0 (instead of RemovableMedia) prevents parallel processing of Write requests?
That sounds like a bug to me. (and we don't want to use "removable media", as our cbfs drive is not removable).
Could you investigate?

Thx for your help.
Posted: 04/21/2015 11:12:58
by Eugene Mayevski (Team)

Those flags are not processed by CBFS - they are passed to the OS. So I believe it's Windows that somehow changes it's policy for filesystem requests in various cases.

However I'd recommend to use RemovableMedia flag unless it affects some functionality that you use. When RemovableMedia flag is set, the OS tends to move some information to memory. For example for EXE files it used to (don't know how it behaves now) load the image completely to memory when executing them. Such approach would speed up operations in most CBFS-related scenarios.

Sincerely yours
Eugene Mayevski



Topic viewed 3155 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!