EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Performance issue during files/folders deletion

Also by EldoS: RawDisk
Access locked and protected files in Windows, read and write disks and partitions and more.
#28527
Posted: 02/24/2014 10:02:26
by William Levra-Juillet (Priority Standard support level)
Joined: 09/05/2013
Posts: 49

Hi,

We moved away from Dokan and now using cbfs. We noticed something weird.
We have a test that measures the performance to recursively delete a folder full of files and subfolders (from Explorer or from Dos prompt).

On some machines, we achieve expected/reference speed (let say 200 files deleted/sec).
On other machines, it's more than 5 times slower (~40 files/sec).
Machines are same specs (hardware) and same OS (win8.1 x64)

Note that using Dokan, deletion speed is consistent on all our machines (~200 files/sec).

For example, to delete "root" where root contains: \root\f1\f2\f3\file.txt

Callbacks at "full" speed:
- GetFileInfo (\root\f1\f2\f3\file.txt)
- CanBeDeleted (\root\f1\f2\f3\file.txt)
- DeleteFile (\root\f1\f2\f3\file.txt)

Callbacks at "slow" speed:
- GetFileInfo (\root\f1\f2\f3\file.txt)
- CanBeDeleted (\root\f1\f2\f3\file.txt)
* GetFileInfo (\root)
* GetFileInfo (\root\f1)
* GetFileInfo (\root\f1\f2)
* GetFileInfo (\root\f1\f2\f3)
* OpenDir (\root\f1\f2\f3)
* EnumerateDirectory (\root\f1\f2\f3) mask=file.txt
* CloseDir (\root\f1\f2\f3)
* GetFileInfo (\root)
* GetFileInfo (\root\f1)
* GetFileInfo (\root\f1\f2)
* OpenDir (\root\f1\f2)
* EnumerateDirectory (\root\f1\f2) mask=f3
* CloseDir (\root\f1\f2)
* GetFileInfo (\root)
* GetFileInfo (\root\f1)
* OpenDir (\root\f1)
* EnumerateDirectory (\root\f1) mask=f2
* CloseDir (\root\f1)
* GetFileInfo (\root)
* GetFileInfo (\root)
* OpenDir (\root)
* EnumerateDirectory (\root) mask=f1
* CloseDir (\root)
- DeleteFile (\root\f1\f2\f3\file.txt)

Notice all the extra steps marked with * !
Everytime a file is about to be deleted, the whole folder hierarchy is re-parsed :(
So far, I had no luck trying to find why are these extra steps here (only on some machines and never happens with dokan).

Any ideas or suggestions?
I can't use Process monitor, as the drive is mapped as a network drive, and nothing appear in procmon AddMountingPoint("O:;COMP_NAME;FSNAME", CBFS_SYMLINK_NETWORK, 0);

Thx for your help!
#28528
Posted: 02/24/2014 10:07:59
by Eugene Mayevski (EldoS Corp.)

How exactly do you perform deletion operation? If you use Explorer, try deleting files using command-line and see if this makes a difference.


Sincerely yours
Eugene Mayevski
#28529
Posted: 02/24/2014 10:13:03
by William Levra-Juillet (Priority Standard support level)
Joined: 09/05/2013
Posts: 49

Thx Eugene,

Same thing happens if we delete from dos prompt, using "rmdir /S".
#28530
Posted: 02/24/2014 10:31:34
by Eugene Mayevski (EldoS Corp.)

Thank you.

Please also clarify whether you have Metadata cache enabled or disabled?


Sincerely yours
Eugene Mayevski
#28531
Posted: 02/24/2014 10:42:47
by William Levra-Juillet (Priority Standard support level)
Joined: 09/05/2013
Posts: 49

All cache mechanism disabled:
SetFileCacheEnabled(FALSE);
SetMetaDataCacheEnabled(FALSE);
SetNonexistentFilesCacheEnabled(FALSE);

Also:
SetMinWorkerThreadCount(2);
SetMaxWorkerThreadCount(2); // 2 is legacy from dokan
SetSerializeCallbacks(FALSE);
SetParalleledProcessingAllowed(TRUE);

The mapped drive is a "proxy" to a network remote device, and if multiple PCs/cbfs access the same network device, then enabling caching can give weird behaviour...
#28533
Posted: 02/24/2014 11:17:25
by Volodymyr Zinin (EldoS Corp.)

Because MetaDataCache is disabled you get lots of GetFileInfo requests. It is correct behavior.
In some cases (if the parent directory remains opened during deletion of files) the GetFileInfo requests for the parent directories don't come even if MetaDataCache is disabled. Perhaps such difference in speed is because of it.
If it's possible try to enable the meta data cache and check the speed again.

Thanks.
#28536
Posted: 02/25/2014 05:41:31
by William Levra-Juillet (Priority Standard support level)
Joined: 09/05/2013
Posts: 49

Thx Vladimir,

Yes, if I enable MetaData cache, then speed improves, and a lot of GetFileInfo disappear.
But as I said, it raises some problems when accessing the same network device from 2 different PCs:

on PC1:
- create \root\f1
- copy some files into f1

on PC2:
- delete \root\f1

Go back to PC1:
- PC1 thinks that f1 still exists, and explorer reports some weird error (even though that f1 is not displayed anymore). Can't seem to flush/reset the metadata cache...

We have our own cache mechanism in our callbacks (because we had no choice when using dokan). We have a "time to live" value (set to a few seconds, configurable).
So a cached file expires after Xsec.
This allow us to get rid of the problem mentioned above.

Having said that, using our own cache is not as efficient as yours, as I suppose your cache is implemented driver/kernel side, opposed to our cache (implemented user/callback side) :(

Any chance we could have some control on the cbfs cache lifetime?
Any suggestions?

Thx!
#28537
Posted: 02/25/2014 06:18:43
by Volodymyr Zinin (EldoS Corp.)

Quote
William Levra-Juillet wrote:
when accessing the same network device from 2 different PCs:

on PC1: - create \root\f1 - copy some files into f1

on PC2: - delete \root\f1

Go back to PC1: - PC1 thinks that f1 still exists, and explorer reports some weird error (even though that f1 is not displayed anymore). Can't seem to flush/reset the metadata cache...

Do you mean that PC1 accesses the files/directories via the CBFS disk, but PC2 accesses them directly (i.e. not the CBFS disk)? If no please describe more detailed the architecture of your application and how do the PC1 and PC2 perform access to the files (how they are shared, etc)?
Thanks.
#28538
Posted: 02/25/2014 06:36:44
by William Levra-Juillet (Priority Standard support level)
Joined: 09/05/2013
Posts: 49

Sorry it wasn't clear.
We use cbfs (or dokan) to "mount" locally a network device.
The network device is hosting the 2real" file system and is accessed via a proprietary network protocol.
The same physical device can be accessed simultaneously from different PCs (via LAN).

PC1 is running CBFS, drive mapped locally, accessing device1.
PC2 is running CBFS, drive mapped locally, accessing device1.

So, cache in both PC1 and PC2 can be out of sync.
That's why we added a "ttl" value in our own cache, so after a while (a few seconds), the cache is flushed.

I would prefer using the cbfs cache as it's kernel side (so potentially more efficient, and minimize context switching between kernel code and user mode code).
But due to the above problem (cache out of sync), we can't really use it as it is now.

Does that make sense?
#28539
Posted: 02/25/2014 06:48:12
by Eugene Mayevski (EldoS Corp.)

You need to monitor the contents of the network device being exposed via CBFS, and if it changes, use NotifyDirectoryChange method to refresh contents of CBFS caches (and notify the OS about the remote changes).


Sincerely yours
Eugene Mayevski
Also by EldoS: RawDisk
Access locked and protected files in Windows, read and write disks and partitions and more.

Reply

Statistics

Topic viewed 2965 times

Number of guests: 2, 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!