Samba reading old data - SMB

This is a discussion on Samba reading old data - SMB ; Hi all, We are running Samba on a QNX system connected to a WinMe Laptop. The QNX share is set up as a network drive on the laptop. After modifying a file under QNX, the file sometimes appears unchanged, when ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Samba reading old data

  1. Samba reading old data

    Hi all,

    We are running Samba on a QNX system connected to a WinMe Laptop. The QNX
    share is set up as a network drive on the laptop.

    After modifying a file under QNX, the file sometimes appears unchanged,
    when a Windows application reads it. It seems there is some buffer mechanism
    (on Windows? on Samba?). How can I force the win app always to read the
    current (updated) file contents?


    Thanks
    Thomas





  2. Re: Samba reading old data

    GW wrote:
    > Hi all,
    >
    > We are running Samba on a QNX system connected to a WinMe Laptop. The QNX
    > share is set up as a network drive on the laptop.
    >
    > After modifying a file under QNX, the file sometimes appears unchanged,
    > when a Windows application reads it. It seems there is some buffer mechanism
    > (on Windows? on Samba?).


    Probably on Windows. See below

    > How can I force the win app always to read the
    > current (updated) file contents?


    From the description, you are having problems with "oplocks". The Samba
    documentation ("Speed.txt") says this about oplocks...

    OPLOCKS
    -------

    Oplocks are the way that SMB clients get permission from a server to
    locally cache file operations. If a server grants an oplock
    (opportunistic lock) then the client is free to assume that it is the
    only one accessing the file and it will agressively cache file
    data. With some oplock types the client may even cache file open/close
    operations. This can give enormous performance benefits.

    With the release of Samba 1.9.18 we now correctly support opportunistic
    locks. This is turned on by default, and can be turned off on a share-
    by-share basis by setting the parameter :

    oplocks = False

    We recommend that you leave oplocks on however, as current benchmark
    tests with NetBench seem to give approximately a 30% improvement in
    speed with them on. This is on average however, and the actual
    improvement seen can be orders of magnitude greater, depending on
    what the client redirector is doing.

    Previous to Samba 1.9.18 there was a 'fake oplocks' option. This
    option has been left in the code for backwards compatibility reasons
    but it's use is now deprecated. A short summary of what the old
    code did follows.

    LEVEL2 OPLOCKS
    --------------

    With Samba 2.0.5 a new capability - level2 (read only) oplocks is
    supported (although the option is off by default - see the smb.conf
    man page for details). Turning on level2 oplocks (on a share-by-share basis)
    by setting the parameter :

    level2 oplocks = true

    should speed concurrent access to files that are not commonly written
    to, such as application serving shares (ie. shares that contain common
    .EXE files - such as a Microsoft Office share) as it allows clients to
    read-ahread cache copies of these files.

    Old 'fake oplocks' option - deprecated.
    ---------------------------------------

    Samba can also fake oplocks, by granting a oplock whenever a client
    asks for one. This is controlled using the smb.conf option "fake
    oplocks". If you set "fake oplocks = yes" then you are telling the
    client that it may agressively cache the file data for all opens.

    Enabling 'fake oplocks' on all read-only shares or shares that you know
    will only be accessed from one client at a time you will see a big
    performance improvement on many operations. If you enable this option
    on shares where multiple clients may be accessing the files read-write
    at the same time you can get data corruption.


    It sounds to me that Windows is "oplock"ing the file, and caching the data.
    Your QNX changes to the data are made outside of the oplock mechanism, and
    thus are not reflected in the cache of data that the Windows system has. Since
    Samba doesn't manage your unix file use (i.e. changes to files made from
    within QNX, but not with Samba tools) Samba doesn't have a mechanism to
    propogate forward the changed data, or prevent you from modifiying an oplocked
    file.

    There /might/ be ways that Samba can locally lock an oplocked file so that QNX
    /cant/ update it; you probably should ask the samba team
    (http://www.samba.org/) about it though.


    --
    Lew Pitcher

    Master Codewright and JOAT-in-training
    Registered Linux User #112576 (http://counter.li.org/)
    Slackware - Because I know what I'm doing.


  3. Re: Samba reading old data

    > > How can I force the win app always to read the
    > > current (updated) file contents?

    >
    > From the description, you are having problems with "oplocks". The Samba
    > documentation ("Speed.txt") says this about oplocks...


    It seems it was oplocks. After vetoing oplocks for the shares in question
    the cacheing symptom disappeared.

    Thanks for your help!

    Thomas




+ Reply to Thread