Project

General

Profile

Bug #5317

SMB server delivers old modification time

Added by Gordon Ross over 5 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Start date:
2014-11-13
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:

Description

The illumos SMB server does modification time caching for files with open handles.
It only updates these caches when no other files are open to the same file.

This is extremely problematic when you have software that relies on a windows
client accessing the same file for reading as a unix client for writing (or a zfs receive that
updates the filesystem).

An example sequence:

Client A opens a file \\\\server\\share\\filename for reading and keeps the file open (as it needs to
access the file constantly).

Client B opens the file /volumes/pool/share/filename for writing, updating some portion of the file.

The change from Client B changes the modification timestamp of the file in zfs.
However, ANY OTHER WINDOWS CLIENT querying for the modification time of \\\\server\\share\\filename
will get the OLD time. This is due to the following code:

http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/fs/smbsrv/smb_node.c#1585

The same happens, when you exchange Client B by a snapshot based replication via zfs send/recv.
The recv would normally invalidate the file handles the next time the client that have it open try to
access the smb file hande. (When the clients do not do this immediately - as in our case - the modificaton time
never changes for the windows clients, until you either restart the smb-service or "re-share" the filesystem for smb
OR close all clients with open handles - which we can not do!).

Note that NFS and local processes see the actual mtime. Only the SMB server lies this way.

History

#1

Updated by Gordon Ross over 5 years ago

The reason the SMB server caches modify times as described in this report is for compatibility with Windows applications.
The applications expect that, after setting any times via an SMB handle, all time queries using that handle should return the time that was set on that handle. Furthermore, any I/O on that handle must_not change the modify time of the underlying object, as viewed by not only the current handle, but all queries for times by other handles or by pathname (at least for the SMB service).

Avoiding mtime updates is tricky to implement because those are done for us at the file-system level.

#2

Updated by Electric Monk over 5 years ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100

git commit 5fd03bc0f2e00e7ba02316c2e08f45d52aab15db

commit  5fd03bc0f2e00e7ba02316c2e08f45d52aab15db
Author: Gordon Ross <gwr@nexenta.com>
Date:   2014-11-29T20:44:18.000Z

    5317 SMB server delivers old modification time
    Reviewed by: Bayard Bell <bayard.bell@nexenta.com>
    Reviewed by: Hans Rosenfeld <hans.rosenfeld@nexenta.com>
    Reviewed by: Albert Lee <trisk@nexenta.com>
    Reviewed by: Thomas Keiser <thomas.keiser@nexenta.com>
    Approved by: Robert Mustacchi <rm@joyent.com>

Also available in: Atom PDF