[Bug 2578] New: file write performance over NFS very poor due to dup+write+close

[Wine Bugs]

http://bugs.winehq.org/show_bug.cgi?id=2578

           Summary: file write performance over NFS very poor due to
                    dup+write+close
           Product: Wine
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: wine-misc
        AssignedTo: wine-bugs at winehq.org
        ReportedBy: greg at electricrain.com


I run wine on a diskless workstation to run some windows video transmogrifying
applications.  Needless to say, video files are huge so this app does a lot of
IO.  Under wine, the effective write speed of the application is reduced to a
few hundred kbytes/sec on nfs filesystems.  Performance is probably reduced on
local disks as well (i don't have wine on a system with a disk to test that) as
the close() presumably waits for the data to be committed to disk.

Doing an strace of the wine process that does the disk IO shows:

rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0
rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [RTMIN], 8) = 0
write(16, "&\0\0\0\0\0\0\0\0\0\0\0d\0\0\0\0\0\0@\0\0\0\0\0\0\0\0\0"..., 64) = 64
read(15, "\0\0\0\0\0\0\0\0\24\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64
rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0
dup(20)                                 = 23
write(23, "\0\0\1\272D\37T\222LU\1\211\303\370\0\0\1\300\7\354\201"..., 2048) = 2048
close(23)                               = 0
... repeated for a long long time ...

A check in /proc/PID/fd/ shows that 20 is indeed the output file (15 and 16 are
the pipes between the wine processes).  Not seen here is the input file (17)
which is read much more efficiently in 3 128k chunks every so often (though it
is read in an unnecessary dup+read+close sequence which causes extra NFS getattr
latency)

tcpdump on the nfs client shows that three round trip latencies are involved in
every 4096 bytes that wine writes:

  getattr + response, write + response, commit + response.

with a normal linux program that doesn't close its fd (forcing the commit and
the getattr before the next write) writing goes at full speed.

I have observed this behaviour with every version of wine i've used in the past
year.  Currently i'm using 20041019.  It occurs regardless of if the client is
running a linux 2.4 or 2.6 kernel.  The kernel is doing the correct thing. 
Close forces a commit to ensure that the data is on stable storage before
returning (close will return an error otherwise; wine doesn't appear to check
for an error on close).

Proposed fix: stop the dup+close nonsense.  Grepping thru the wine code I'm
guessing that it is in dlls/ntdll/server.c where this all occurs with the
wine_server_handle_to_fd() and wine_server_release_fd() functions that implement
a dup() and a close() respectively.

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.