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@xxxxxxxxxxxxxx> --- 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html