Conference decwet::windows-nt

5903.0. "NFS performance problem form explorer" by BACHUS::VANHAVERE (Willy Van Havere 8786) Fri Apr 11 1997 07:28

    
    
    
    
    
    
    
    
    
    
    When copying a large (+10Mbytes) file from a local NT4.0 ntfs volume to
    a network driver (NFS volume exported by VMS, UCX and using MAESTRO
    from
    Humming Bird) using the explorer we get a very low throughput.
    
    Doing the same from a dos box using copy doesn't have this problem.
    
    In the case of the explorer we see a large ~3minutes gap in which the
    NFS$SERVER is doing lots of IO's not durectly related to transfering
    data which we assume is what is described in the note I added below.
    
    Now ofcourse ther question is can we make the explorer behave
    differently more like the copy from a dosbox.
    
    -----------------------------------------------------------------------
    
              <<< LASSIE::UCXAXP$DKA0:[NOTES$LIBRARY]UCX.NOTE;1 >>>
                      -< DEC TCP/IP Services for OpenVMS >-
    
================================================================================
Note 217.8      problem linking big file on NFS served container          8 of 8
LASSIE::CORENZWIT "stuck in postcrypt queue"         32 lines  20-JUN-1994 15:41
                      -< current status of this problem >-
--------------------------------------------------------------------------------
    To bring this topic up to date with off-line progress and progress
    since the last mail:...
    
    1.  This problem is connected with writing sparse files.
    
    Sparse file tutorial as I understand it:  Unix file systems allow files
    to have allocation holes in them.  That is, if you write to a file
    offset way past the last allocated block, a non-consecutive block gets
    allocated.  Any reads to the intervening unallocated blocks result in a
    null-filled data buffer, but those nulls do not get stored anywhere on
    the disk. 

    ODS-2 does not support such a thing.  Therefore, when the NFS  server
    on a VMS system gets one of these writes to a non-contiguous file
    offset, it has to allocate all the intervening blocks and write nulls
    into them, which can take quite a bit of time.  

    The Unix ld is known to do some writes of this kind.
    
    2.  The client was doing a soft mount, which means operations that have
    used up all their timeouts (-o retrans) are not retried.  With a hard
    mount, the client starts the whole operation over again with the
    original timeout value.
    
    Some combination of adjustments of -o timeo and -o retrans and/or using
    a hard mount should suffice as a workaround.
    
    3.  There has in fact been a slow down of this type of sparse write
    operation between V2.0E and V3.1.  In my test environment V3.1 is about
    half as fast.  We are still working on finding the reason for this.
    
    Julie