Re: Cygwin Filesystem Performance degradation 1.7.5 vs 1.7.7, and methods for improving performance
On 9/22/2010 7:44 AM, Christopher Faylor wrote: What is /mnt/hgfs/C in this case? How is it mounted? HGFS is the Host-Guest File System, a VMware technology that lets it export host volumes to the guest in a high-speed way. If you used old versions of VMware Workstation for Linux, you may remember that they used to ship a version of Samba to export Linux-side filesystems to the Windows guest. Now they use their proprietary HGFS technology instead. In addition to being smaller and faster than Samba, it works with all supported host and guest combinations, and it removes a dependency. I believe Yoni's point is that the Linux guest -> HGFS/VMware -> Windows native path apparently has less code in it than the Cygwin -> Windows native code path.
Re: Cygwin Filesystem Performance degradation 1.7.5 vs 1.7.7, and methods for improving performance
On Tue, Sep 28, 2010 at 08:56:18AM -0600, Warren Young wrote: >On 9/22/2010 7:44 AM, Christopher Faylor wrote: >> >> What is /mnt/hgfs/C in this case? How is it mounted? > >HGFS is the Host-Guest File System, a VMware technology that lets it >export host volumes to the guest in a high-speed way. > >If you used old versions of VMware Workstation for Linux, you may >remember that they used to ship a version of Samba to export Linux-side >filesystems to the Windows guest. Now they use their proprietary HGFS >technology instead. In addition to being smaller and faster than Samba, >it works with all supported host and guest combinations, and it removes >a dependency. > >I believe Yoni's point is that the > > Linux guest -> HGFS/VMware -> Windows native > >path apparently has less code in it than the > > Cygwin -> Windows native > >code path. 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 wouldn't even be surprised to see that the old Samba implementation was faster. cgf
Re: Cygwin Filesystem Performance degradation 1.7.5 vs 1.7.7, and methods for improving performance
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.
Re: Cygwin Filesystem Performance degradation 1.7.5 vs 1.7.7, and methods for improving performance
It's time to move this discussion out of cygwin-patches and into cygwin-developers. I'd appreciate it if people continued over there. cgf
