Re: Cygwin Filesystem Performance degradation 1.7.5 vs 1.7.7, and methods for improving performance

[Warren Young <warren at etr-usa dot com>]

On 9/28/2010 9:10 AM, Christopher Faylor wrote:
> It isn't extremely surprising that Linux access speed for a filesystem
> in a simulated environment, which presumably does not go through
> multiple layers of DLLs, would be faster than Cygwin.

I think it more likely that the HGFS driver doesn't try to preserve full 
POSIX semantics.  There's plenty of precedent: vfat, iso9660...  One 
could probably verify this faster by examining the driver's source code 
(http://open-vm-tools.sourceforge.net/) than by tracing syscalls.

If that's the explanation, it points at a possible path forward.

On Linux, these secondary filesystems aren't expected to provide full 
POSIX semantics, simply because they are secondary.  No one cries very 
hard that you can't make symlinks on a FAT-formatted USB stick.

Yet, there's probably no technical reason you couldn't get a POSIX-like 
system to run on a crippled filesystem.  It's probably even been done 
lots of times before in the embedded world.  Some of the PC Unix systems 
from the 80s and early 90s were pretty screwy in this way, too.  Screwy 
doesn't prevent you from doing useful work, though.

Would it not be useful to have a mode in Cygwin that purposely skips any 
POSIX semantics that it can't get for free by making the POSIX syscalls 
nothing more than thin wrappers around the nearest equivalent Win32 API? 
 If you put it in this mode and it breaks, you get to keep both pieces. 
 There are those who would happily accept the speed increase for loss 
of some functionality.  I wouldn't, but some would.  I'd bet a lot of 
the 3PPs are in that group, since they know their target environment 
very well.