Bug 4307 - Samba always uses read-write leases to implement oplocks
Summary: Samba always uses read-write leases to implement oplocks
Status: NEW
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.23d
Hardware: x86 Linux
: P3 minor
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
Depends on:
Reported: 2006-12-23 11:43 UTC by Dan Fulger
Modified: 2006-12-23 11:43 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Dan Fulger 2006-12-23 11:43:11 UTC
I tried to search for this on mailing lists and bugzilla, but I couldn't find anything, even though it looks like an old problem. I'm sorry if this is already known.

I have a directory which is exported through both Samba and NFS. Samba always requests an exclusive (read-write) lease from the Linux kernel even if the request was for a level 2 oplock.

When there is an exclusive lease on a file, the Linux NFS server always reports the mtime of that file as equal to the current time. Though the mtime remains unchanged on the server, all the NFS clients see the current time in the place of the mtime of the file. 
The mtime of the file (as seen through NFS) changes back to normal (moves back in time) when the lease is broken, and this is causing me problems with a search indexing application. 

The following function in linux-26/fs/locks.c is responsible:

 *	lease_get_mtime
 *	@inode: the inode
 *      @time:  pointer to a timespec which will contain the last modified time
 * This is to force NFS clients to flush their caches for files with
 * exclusive leases.  The justification is that if someone has an
 * exclusive lease, then they could be modifiying it.
void lease_get_mtime(struct inode *inode, struct timespec *time)
	struct file_lock *flock = inode->i_flock;
	if (flock && IS_LEASE(flock) && (flock->fl_type & F_WRLCK))
		*time = current_fs_time(inode->i_sb);
		*time = inode->i_mtime;

More worring is that the SMB user did not have write privileges for the file, and all the opens were read-only as a result; I find it quite unexpected for a read-only open to make a change to the mtime of a file.