Re: [PATCH] Fix checkout of large files to network shares under Windows XP

["René Scharfe" <rene.scharfe@lsrfire.ath.cx>]

Am 20.04.2010 22:49, schrieb René Scharfe:
> Am 20.04.2010 14:42, schrieb Sebastian Schuberth:
>> I've updated work/issue-409 in 4msysgit.git accordingly.
> 
> This patch doesn't help in the test case I cobbled together quickly.
> It's a Windows XP SP3 client on VMWare mapping a file share exported by
> a Netapps filer, over a VPN.  It's very slow, and I admit that it's a
> weird setup.  I wouldn't actually use it that way, but couldn't find
> another file share momentarily.
> 
> I can check out a 1MB file, but checking out a 32MB file fails.  I've
> added a fprintf() to the loop and I can see that it's halving the size
> and retries, as intended, until it eventually hits zero.
> 
> The file is created using the correct file size (32MB), though.The first
> failed write(2) call needs to be undone somehow before we can try again,
> it seems.  Do we have to seek back or truncate the file?
> 
> Replacing the body of mingw_write() with the following line allows me to
> check out the 32MB file, by the way:
> 
> 	return write(fd, buf, min(count, 1024 * 1024));

OK, I've been searching the web looking for documentation that explains
the issue, but haven't found any watertight evidence.

With Process Monitor [1], I found out that local write() calls are
translated to WriteFile() calls with a maximum size of 64KB on Windows XP
and 256KB on Vista.  Writes to a network drive are translated to
WriteFile() calls without applying a size cap.

In a forum discussion [2], someone explained that unbuffered writes using
WriteFile() have certain size limits, depending on the processor:

	x86:  67,076,096
	X64:  33,525,760
	IA64: 67,051,520

This post is cited by an MS employee in the comment section of the online
documentation for WriteFile() [3].

A Knowledge Base article [4] documents a size limit of 67,076,095 for
fwrite() to a file on a network drive.  fwrite() calls translate to
WriteFile() calls, too.  The reason for this is said to be an OS problem,
but no OS versions are named at all in this article.

Please note that the size limit of fwrite() is suspiciously close to the
one for an unbuffered WriteFile().

In my test setup, write() calls to a network drive fail with a size
parameter of 32MB, while with 33,525,760 bytes they succeed.

Based on these two observations, I suspect that there's a connection
between writes to a network drive and unbuffered writes.  Perhaps writes
over the net are passed to the NIC driver in one piece which is locked
into RAM?

The connection is a bit weak (it would be good to have someone comment on
this who actually knows something about this topic and doesn't have to
guesswork through a bunch of websites), but I think it's enough to create
a patch.  Based on the numbers above, I think 31MB is a good size to
simply cap writes.

When we learn that other systems need a lower limit still, we can easily
reduce our cap, without affecting local performance.

It would be nice to reach chris.gcode, who originally reported this
problem [5], and ask him to test.  I couldn't find an email address on
that webpage, though.  His proposed patch there also used an upper limit
slightly below 32MB, but tried to compensate for capping by looping until
the full requested size was written.  That's not really needed.

René


[1] http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
[2] http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/fef1c9b5-fd92-4ada-8de5-44c2eb30b516
[3] http://msdn.microsoft.com/en-us/library/aa365747(VS.85).aspx#5
[4] http://support.microsoft.com/kb/899149
[5] http://code.google.com/p/msysgit/issues/detail?id=409

-- >8 --
Bigger writes to network drives on Windows XP fail.  Cap them at 31MB to
allow them to succeed.  Callers need to be prepared for write() calls
that do less work than requested anyway.

On local drives, write() calls are translated to WriteFile() calls with
a cap of 64KB on Windows XP and 256KB on Vista.  Thus a cap of 31MB won't
affect the number of WriteFile() calls which do the actual work.  There's
still room for some other version of Windows to use a chunk size of 1MB
without increasing the number of system calls.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
 compat/mingw.c |   17 +++++++++++++++++
 compat/mingw.h |    3 +++
 2 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/compat/mingw.c b/compat/mingw.c
index f90a114..9a8e336 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -140,6 +140,23 @@ int mingw_open (const char *filename, int oflags, ...)
 	return fd;
 }
 
+#undef write
+ssize_t mingw_write(int fd, const void *buf, size_t count)
+{
+	/*
+	 * While write() calls to a file on a local disk are translated
+	 * into WriteFile() calls with a maximum size of 64KB on Windows
+	 * XP and 256KB on Vista, no such cap is placed on writes to
+	 * files over the network on Windows XP.  Unfortunately, there
+	 * seems to be a limit of 32MB-28KB on X64 and 64MB-32KB on x86;
+	 * bigger writes fail on Windows XP.
+	 * So we cap to a nice 31MB here to avoid write failures over
+	 * the net without changing the number of WriteFile() calls in
+	 * the local case.
+	 */
+	return write(fd, buf, min(count, 31 * 1024 * 1024));
+}
+
 #undef fopen
 FILE *mingw_fopen (const char *filename, const char *otype)
 {
diff --git a/compat/mingw.h b/compat/mingw.h
index 7c2ab64..0e3e743 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -170,6 +170,9 @@ int link(const char *oldpath, const char *newpath);
 int mingw_open (const char *filename, int oflags, ...);
 #define open mingw_open
 
+ssize_t mingw_write(int fd, const void *buf, size_t count);
+#define write mingw_write
+
 FILE *mingw_fopen (const char *filename, const char *otype);
 #define fopen mingw_fopen
 
-- 
1.7.1