Hi, I am using AIX 4.1.5 and found the following problem with oplocks. On an AIX 4.1.5 system I created the file xx with the contents (0000) Do a ls -l on the file -rw-r--r-- 1 rcblach rtp403 7 Jan 29 11:09 xx on a win95 sytem with the file mapped on my F: type xx (0000) do a dir on the file dir xx Volume in drive F is RCBLACH Directory of F:\ xx 7 01-29-98 11:09a xx xx bck 16,401 01-29-98 10:31a xx.bck 2 file(s) 16,408 bytes 0 dir(s) 597,344,256 bytes free ------ now on the AIX sytem change the file xx to (0000 ) and do an ls on the file -rw-r--r-- 1 rcblach rtp403 8 Jan 29 11:12 xx now on the win95 system do a dir of the file Volume in drive F is RCBLACH Directory of F:\ xx 8 01-29-98 11:12a xx xx bck 16,401 01-29-98 10:31a xx.bck NOW type the file and the results are type xx (0000) -------------- HMMMMMM, the correct length is reported, but the old cached version of the file is present. Now heres the very intersting point. If I edit the file, the correct version is retrieved. there edit xx shows (0000 ) To overcome this I have set oplocks =False in the smb.conf file. Any comments??? is this a bug??? Chip Blach
Ralph Blach wrote :> HMMMMMM, the correct length is reported, but the old cached version of > the file is present. > Now heres the very intersting point. If I edit the file, the correct > version is retrieved. > > Any comments??? is this a bug???Well, this is something that is going to come up more often now Samba supports oplocks. The short answer, it isn't a bug in Samba (more a current technical limitation of user mode CIFS/SMB support). The long answer : Short of modifying the underlying UNIX kernel for every operating system that Samba runs on, there is no way to ensure that access to a file from a UNIX process sees the same data as access to a file from the Windows client that has oplocked the file. What is happening ----------------- The Windows client opens the file and obtains an oplock on it. This means the Windows client believes it has exclusive access to the data in the file, and will be notified if any other process attempts to modify the file. The problem is that this invariant is not true if you access the file from a UNIX process. The UNIX kernel doesn't notify Samba when some other process does a cat (for example) on the file, so Samba doesn't know that the file has been accessed from the UNIX side and therefore cannot break the oplock. For UNIX'es that have source code available (Linux, FreeBSD for example) it may be possible to modify Samba so that it interacts with the kernel in the same way that an automounter does - ie. any traversal into a particular inode causes the accessor to be suspended whilst an up-call into user space is made to Samba, which can then break the oplock and ensure a consistant view of the file for the UNIX process. Unless the UNIX vendors make such a facility generally available (Sun have expressed an interest in doing this) and Samba is extended to support such a facility then you should not use oplocks on a share that contains files being modified both by UNIX processes and by Windows clients - they will see inconsistant views of the data. Network appliance (full disclaimer here, my wife works for them as their CIFS/SMB Product Marketing Manager) have solved this problem in their implementation by causing access by UNIX/nfs clients to break oplocks granted to Windows clients, so they can guarentee a consistant view of the data to both clients (however, they control the OS so they can do this easier than the Samba Team can modify Solaris/IRIX/AIX etc. :-). Hope this clears up the nature of the problem, Cheers, Jeremy Allison, Samba Team. -- -------------------------------------------------------- Buying an operating system without source is like buying a self-assembly Space Shuttle with no instructions. --------------------------------------------------------
Ralph Blach <rcblach@raleigh.ibm.com> asked about oplocks and caching, and Jeremy Allison <jallison@whistle.com> replied:> Short of modifying the underlying UNIX kernel > for every operating system that Samba runs on, > there is no way to ensure that access to a file > from a UNIX process sees the same data as access > to a file from the Windows client that has > oplocked the file.There are three ``traditional'' approaches to detecting and managing concurrent access to files on unix... 0: don't. 1: use file/inode times 2: use locks 0 is the normal one, which was frustrating to my colleagues in a previous life, because we couldn't segregate our data into sets that were never accessed except by out applications... So we implemented a form of opportunistic locking for our own files (which were the 90% case), with heuristics built in for the others. Heuristic #1 was implemented by storing a date in the ``lock'' variable for a file. The date was the file date when we established the lock. If we detected an unexpected date change on a close or fflush, we did the usual ``someone else is editing your file'' shtick in our application, and made or broke the oplocks depending on the user's reply. In the non-interactive apps, which were more common, we just broke the locks and let the apps recover and roll forward. I suspect this is close to the PC behaviour: the author modelled it on MS locking (:-)) On some architectures we actually called flock(fd,LOCK_SH|LOCK_NB) and LOCK_EX as part of the process, but the latency cost performance on a few older machines. Modern OSs were ok. Methinks a date check might be useful if it can be done with limited performance impacts. The risk is that you might need to check file dates far too often, thus causing repeated rereading of the inode. See various white papers on nfs and cachefs for hints at what people have found in practice... --dave -- David Collier-Brown, | Always do right. This will gratify some people 185 Ellerslie Ave., | and astonish the rest. -- Mark Twain Willowdale, Ontario | davecb@hobbes.ss.org, canada.sun.com M2N 1Y3. 416-223-8968 | http://java.science.yorku.ca/~davecb
Hi all, In IRIX (5.x and 6.x) there's an interesting posibility for (at least partially) addressing the UNIX-side problems with op-locks. There exists a mechanims known as 'fam' which uses a kernel level device to track file changes efficiently A user-land process can express interest in a file, and will recieve notification when that file changes. Here followeth the main man-page. FAM(1M) FAM(1M) NAME fam - file alteration monitor SYNOPSIS /usr/etc/fam [ -t NFS polling interval ] DESCRIPTION Fam is a server that tracks changes to the file system and relays these changes to interested applications. Applications such as WorkSpace(1G) and Mailbox(1G) present an up-to-date view of the file system. In the absence of fam, these applications and others like them would be forced to poll the file system to detect changes. Fam is considerably more efficient. Applications can request fam to monitor any files or directories in the file system. When fam detects changes to these files, it notifies the appropriate application. Fam(3X) provides a programmatic interface to fam. Fam is informed of file system changes as they happen by the IRIX kernel through the imon(1M) pseudo device driver. Currently, fam servers do not communicate with each other and consequently, they poll to determine the state of NFS mounted file systems. The -t option specifies the polling interval in seconds. The default polling interval is 3 seconds. Since fam is invoked by inetd(1M), you must edit the /etc/inetd.conf file to change the polling interval. SEE ALSO imon(1M), fam(3X), inetd(1M), workspace(1G), mailbox(1G) Page 1 If anyone is interested in the API (fam(3X)) then I'll gladly send it to them. (It's several pages so I'll not send it to the list). Mac Assistant Systems Adminstrator @nibsc.ac.uk dmccann@nibsc.ac.uk Work: +44 1707 654753 x 285 Everything else: +44 956 237670 (anytime)