Bug 4397 - concurrent access to microsoft access database file is VERY slow
concurrent access to microsoft access database file is VERY slow
Status: NEW
Product: Samba 3.0
Classification: Unclassified
Component: File Services
3.0.23c
x86 Linux
: P3 normal
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-14 08:08 UTC by cornel panceac
Modified: 2007-02-14 08:08 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description cornel panceac 2007-02-14 08:08:09 UTC
there's an (small) networked accounting application wich has it's files shared on a linux machine running fedora core 6 with selinux enabled and firewalled.
all is good until two or more users work in the same point (with same files), when moving from one table filed to another takes seconds.

samba version is samba-3.0.23c-2. 

ports open on server:
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds

relevant section in smb.conf:

[driveo]
        oplocks = false
        level2 oplocks = false
#       kernel oplocks = false
        path = /mnt/contab/driveo
        writable = yes
        valid users = guzu
        create mask = 0777
        directory mask = 0777

ethtool output:
# ethtool eth0
Settings for eth0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
        Advertised auto-negotiation: Yes
        Speed: 100Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 32
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: pumbg
        Wake-on: d
        Current message level: 0x00000007 (7)
        Link detected: yes

clients are all windows xp sp2 with microsoft office 2003 professional installed full.

what MAY be relevant:

application is based on m$ access 97 and has one so called "runtime" installed on another directory than m$ office.

any help would be greatly appreciated.