3 ms·

>Mapping = CreateFileMappingW(Handle, 0, PAGE_READWRITE, 0, FileSize, 0); So it is more a "case" not handled by dokan rather that all memory mapped not handled

by IsBisu 10y ago

>Mapping = CreateFileMappingW(Handle, 0, PAGE_READWRITE, 0, FileSize, 0); So it is more a "case" not handled by dokan rather that all memory mapped not handled ? Is this made in purpose just to remove dokan from the bench ? >The lock exists on WinFsp/MEMFS. It is just taken in a different place: It changes nothing on what I said. You added it on dokan side without reason and not on winfsp memfs. >send me any pull requests that you want for Dokany/MEMFS A pull request will not change that a real application on a non-virtual machine will not see the difference.

billziss 10y ago
> >Mapping = CreateFileMappingW(Handle, 0, PAGE_READWRITE, 0, FileSize, 0); > > So it is more a "case" not handled by dokan rather that all memory mapped not handled ? Is this made in purpose just to remove dokan from the bench ? I do not understand this. Are you familiar with how memory mapping works on Windows? CreateFileMappingW is it. If that API fails you do not have memory mapping. Furthermore I challenge you to show me how Dokany/MEMFS makes this API fail. If you find such an issue I promise to fix it and re-run the tests. >The lock exists on WinFsp/MEMFS. It is just taken in a different place: It changes nothing on what I said. You added it on dokan side without reason and not on winfsp memfs. I added it on Dokan side, because I needed to protect the Dokany/MEMFS data structures against corruption. On the WinFsp side this lock is taken automatically as a convenience (although one can remove it if the file system can cope by using a custom "operation guard" (FspFileSystemSetOperationGuard) -- it is not needed for WinFsp operation). The exact same lock is taken on both sides. There is no unfair advantage to WinFsp. If you design a file system that takes no locks and works on both WinFsp and Dokany, I will be happy to run the tests against that file system. > A pull request will not change that a real application on a non-virtual machine will not see the difference. All the "real application" has to do is to open a file and issues some I/O. Just because Dokany does not cache I/O it will be 9x-10x slower than WinFsp.
- billziss 10y ago
  > The exact same lock is taken on both sides. There is no unfair advantage to WinFsp. If you design a file system that takes no locks and works on both WinFsp and Dokany, I will be happy to run the tests against that file system. Alternatively you can show me that there is a lock already taken within Dokany for this purpose (protection of the data structures of the user mode file system) and I will be happy to remove the lock and rerun the tests.
billziss 10y ago
BTW, here is how FSX calls CreateFileMappingW. https://github.com/billziss-gh/secfs.test/blob/60f9f44b8773122bc3873b162b4136d57f60a131/fstools/src/fsx/win/mman.c#L115 https://github.com/billziss-gh/secfs.test/blob/60f9f44b87731... I do not see a big difference to the fsbench call. It may be that fsbench attempts to make a mapping that is 4MB long. Now you can fix that problem in Dokany ;)

by IsBisu 10y ago

billziss 10y ago

> >Mapping = CreateFileMappingW(Handle, 0, PAGE_READWRITE, 0, FileSize, 0); > > So it is more a "case" not handled by dokan rather that all memory mapped not handled ? Is this made in purpose just to remove dokan from the bench ? I do not understand this. Are you familiar with how memory mapping works on Windows? CreateFileMappingW is it. If that API fails you do not have memory mapping. Furthermore I challenge you to show me how Dokany/MEMFS makes this API fail. If you find such an issue I promise to fix it and re-run the tests. >The lock exists on WinFsp/MEMFS. It is just taken in a different place: It changes nothing on what I said. You added it on dokan side without reason and not on winfsp memfs. I added it on Dokan side, because I needed to protect the Dokany/MEMFS data structures against corruption. On the WinFsp side this lock is taken automatically as a convenience (although one can remove it if the file system can cope by using a custom "operation guard" (FspFileSystemSetOperationGuard) -- it is not needed for WinFsp operation). The exact same lock is taken on both sides. There is no unfair advantage to WinFsp. If you design a file system that takes no locks and works on both WinFsp and Dokany, I will be happy to run the tests against that file system. > A pull request will not change that a real application on a non-virtual machine will not see the difference. All the "real application" has to do is to open a file and issues some I/O. Just because Dokany does not cache I/O it will be 9x-10x slower than WinFsp.

billziss 10y ago
> The exact same lock is taken on both sides. There is no unfair advantage to WinFsp. If you design a file system that takes no locks and works on both WinFsp and Dokany, I will be happy to run the tests against that file system. Alternatively you can show me that there is a lock already taken within Dokany for this purpose (protection of the data structures of the user mode file system) and I will be happy to remove the lock and rerun the tests.

billziss 10y ago

BTW, here is how FSX calls CreateFileMappingW. https://github.com/billziss-gh/secfs.test/blob/60f9f44b8773122bc3873b162b4136d57f60a131/fstools/src/fsx/win/mman.c#L115 https://github.com/billziss-gh/secfs.test/blob/60f9f44b87731... I do not see a big difference to the fsbench call. It may be that fsbench attempts to make a mapping that is 4MB long. Now you can fix that problem in Dokany ;)