Performance issue during files/folders deletion

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

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);

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.

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?

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.

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).

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.

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).