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

[Andy Koppe <andy dot koppe at gmail dot com>]

On 28 September 2010 18:44, Warren Young wrote:
> 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.

Doesn't the 'noacl' mount option provide that already?

Andy