Re: [Samba] delayed mtime updates: configurable?

Re: [Samba] delayed mtime updates: configurable?

[Ralph Boehme]

[-- Attachment #1.1: Type: text/plain, Size: 1163 bytes --]

...adding linux-cifs to the loop...

On 8/1/25 11:35 AM, hede via samba wrote:
> On Sun, 27 Jul 2025 18:45:17 +0200 hede via samba
> <samba@lists.samba.org> wrote:
> 
>> Hi,
>> 
>> SMB 2.1 and up seems to have a delayed mtime update. If writing to
>> a file on the client, the modification time (mtime) for this file
>> gets updated some time after closing. Typically ~1 second after
>> closing the file.
> 
> It's a feature, not a bug. Somehow.
> 
> It's the deferred close feature implementation within cifs.ko which
> delays the mtime update. With "closetimeo=0" the problem is gone.

no idea what the client is doing here, but from a server perspective, 
with current Samba, the write will *immediately* update the mtime on 
disk and report this updated value whenever it is queried. When the 
handle is closed, the server doesn't update the mtime.

A network trace will tell you the truth about what's going on.

Cheers!
-slow

-- 
SerNet Samba Team Lead https://sernet.de/
Samba Team Member      https://samba.org/
Samba Support and Dev  https://samba.plus/services/
SAMBA+ packages        https://samba.plus/products/samba

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [Samba] delayed mtime updates: configurable?

[hede]

On Fri, 1 Aug 2025 12:18:43 +0200 Ralph Boehme <slow@samba.org> wrote:

> no idea what the client is doing here, but from a server perspective, 
> with current Samba, the write will *immediately* update the mtime on 
> disk and report this updated value whenever it is queried. When the 
> handle is closed, the server doesn't update the mtime.

According to a net-trace it seems the client updates mtime several times for a single write event. The last seems done _after_ flushing and before closing the file, so the last mtime change will get flushed not until the deferred close finishes. (i.e. closetimeo seconds after the final write and after closing the file on client-side)

If I comment out the following:

##### in fs/smb/client/file.c in function cifs_close() #####

/*
if (test_and_clear_bit(CIFS_INO_MODIFIED_ATTR, &cinode->flags)) {
        inode->i_ctime = inode->i_mtime = current_time(inode);
}
*/

##### 

... then I do not have problems with vim on client side. 
(my initial problem was that vim complains for a remotely changed file after consecutive writes)

Still, on server side, even then the mtime gets changed not before the final (deferred) close operation has finished.

Btw: Even with this functionality in affect, i.e. not commented out, the mtime update is deferred until the real closing. 
So instead of changing ctime&mtime to current_time() here, maybe some kind of a "flush-command" would be helpful. 

-

Additionally some different thing:

##### in fs/smb/client/file.c in function cifs_readpage_worker()

/* we do not want atime to be less than mtime, it broke some apps */
file_inode(file)->i_atime = current_time(file_inode(file));
if (timespec64_compare(&(file_inode(file)->i_atime), &(file_inode(file)->i_mtime)))
        file_inode(file)->i_atime = file_inode(file)->i_mtime;
else
        file_inode(file)->i_atime = current_time(file_inode(file));

#####

... is it intended to call the same function twice for the "else" case?
And btw.: the same comment and functionality seems to be already in cifs_fattr_to_inode() in fs/smb/client/inode.c 

(I'm not a software developer so please apologise if I do have dumb ideas or questions.)

I tested this with linux 6.1 / cifs 2.40 (Debian Stable) and linux 6.15 / cifs 2.54 (Arch Linux), not with the current master branch.

hede

Re: [Samba] delayed mtime updates: configurable?

[Ralph Boehme]

[-- Attachment #1.1: Type: text/plain, Size: 1559 bytes --]

On 8/1/25 3:58 PM, hede wrote:
> On Fri, 1 Aug 2025 12:18:43 +0200 Ralph Boehme <slow@samba.org>
> wrote:
> 
>> no idea what the client is doing here, but from a server
>> perspective, with current Samba, the write will *immediately*
>> update the mtime on disk and report this updated value whenever it
>> is queried. When the handle is closed, the server doesn't update
>> the mtime.
> 
> According to a net-trace it seems the client updates mtime several
> times for a single write event.
it does it once, before the write. Unfortunately that means sticky mtime 
is in effect which means the time explicitly set is "sticky" and any 
subsequent write must not update the mtime but the explicitly set mtime 
must be preserved. Yes, that it is a little piece of insanity, but that 
is what Windows does and so Samba behaves the same.

The way out of this would be using SMB3 UNIX Extensions (still a very 
new feature, so your mmv with Samba and kernel version), making sure we 
don't use sticky mtime logic on POSIX handles. Unfortunately, that was 
overlooked when in the current implementaion in Samba, I have created a 
WIP MR here:

https://gitlab.com/samba-team/samba/-/merge_requests/4133

It's still a question why the client send the explicit set mtime, might 
be the application or some logic in the kernel.

-slow

-- 
SerNet Samba Team Lead https://sernet.de/
Samba Team Member      https://samba.org/
Samba Support and Dev  https://samba.plus/services/
SAMBA+ packages        https://samba.plus/products/samba

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [Samba] delayed mtime updates: configurable?

[hede]

On Fri, 1 Aug 2025 18:23:22 +0200 Ralph Boehme via samba <samba@lists.samba.org> wrote:

> it does it once, before the write. Unfortunately that means sticky mtime 
> is in effect which means the time explicitly set is "sticky" and any 
> subsequent write must not update the mtime but the explicitly set mtime 
> must be preserved. 

What I can observe here is, the time "preserved" on server side, for the file in the file system on disk, before the final close happens, seems to be some file creation time. None of the client timestamps. The client-sent "sticky" time then seems to get applied only in the end, after the final close. 
I think it should get applied earlier. 

Watching the filesystems directly at client- and server side, the timing of events, is as follows.

mounted via cifs.ko as smb3 with closetimeo=2. 

I'm watching the file via: 
# LANG=C watch -n 0.1 "stat test.txt | grep Modif" 
 - recording a video, analysing afterwards
 - so I probably miss timestamp changes which last less then 0.1 seconds
 
Result:

- given: old file with mtime timestamp 09:23.51.710232900
- both on server and client
- open file in vim, write changes to file
- mtime on client changes to           09:25:34.795869100
- mtime on server firstly remains at   09:23.51.710232900
- mtime on server then changes to      09:25:34.828869245
  (here probably the client already changes the mtime to 09:25:34.823598700 for a short interval, I missed that)
- mtime on client then changes to      09:25:34.856599400
  (this one seems to be the one done in the cifs_close()-function)
- ~2 seconds later (probably the closetimeo interval)
- mtime on server changes to           09:25:34.823598700
- mtime on client changes to           09:25:34.823598700

Watching the file in filesysteme, mtime timestamp of the file on client side changes:
x.71 -> x.79 -> x.85 -> wait 2 seconds -> x.82
-> and vim is complaining that the file has changed while it is opened

With the patches (dirty hack) below, this changes to:

- given: old file with mtime timestamp 09:37:45.099864000
- both on server and client
- open file in vim, write changes to file
- mtime on client changes to           09:39:03.670403100
- mtime on server changes to           09:39:03.670403108 
  (this one I probably missed in the unpatched case above)
- mtime on server changes to           09:39:03.758403493
- mtime on client changes to           09:39:03.754924500
- ~2 seconds later (probably the closetimeo interval)
- mtime on server changes to           09:39:03.754924500

So watching the file in the filesystem on client side now results in:
x.09 -> x.67 -> 0x75 (all within 0.1 seconds)
-> still some 2-seconds-wait on server side
-> no 2-second-wait on client side
-> vim is not complaining
-> still there are multiple updates of the mtime within a short time frame. 

Those probably dirty hacks with side effects are just to show the differences, they are NOT meant as a solution. But I think it shows that there is some kind of a bug/issue here and consequently I think SMB3 UNIX Extensions is not the only option to fix this.

I do not understand why the mtime setting gets delayed at all with the deferred close functionality. Shouldn't they applied independently of each other? The server gets the final timestamp already before this (this is visible via some tcpdump/pcap).

########## (here for Linux 6.1 as in chomeos-6.1) ##########

diff --git a/fs/smb/client/file.c b/fs/smb/client/file.c
index 9b0919d9e337..644ff6595cf1 100644
--- a/fs/smb/client/file.c
+++ b/fs/smb/client/file.c
@@ -1042,9 +1042,9 @@ int cifs_close(struct inode *inode, struct file *file)
                    && cinode->lease_granted &&
                    !test_bit(CIFS_INO_CLOSE_ON_LOCK, &cinode->flags) &&
                    dclose) {
-                       if (test_and_clear_bit(CIFS_INO_MODIFIED_ATTR, &cinode->flags)) {
-                               inode->i_ctime = inode->i_mtime = current_time(inode);
-                       }
+                       //if (test_and_clear_bit(CIFS_INO_MODIFIED_ATTR, &cinode->flags)) {
+                       //      inode->i_ctime = inode->i_mtime = current_time(inode);
+                       //}
                        spin_lock(&cinode->deferred_lock);
                        cifs_add_deferred_close(cfile, dclose);
                        if (cfile->deferred_close_scheduled &&
@@ -4976,8 +4976,8 @@ static int cifs_readpage_worker(struct file *file, struct page *page,
        file_inode(file)->i_atime = current_time(file_inode(file));
        if (timespec64_compare(&(file_inode(file)->i_atime), &(file_inode(file)->i_mtime)))
                file_inode(file)->i_atime = file_inode(file)->i_mtime;
-       else
-               file_inode(file)->i_atime = current_time(file_inode(file));
+       //else
+       //      file_inode(file)->i_atime = current_time(file_inode(file));
 
        if (PAGE_SIZE > rc)
                memset(read_data + rc, 0, PAGE_SIZE - rc);

########## (here for Linux 6.15 as in Arch Linux 6.15.9-arch1) ##########

--- file.c.ori  2025-08-02 08:31:47.006763652 +0200
+++ file.c      2025-08-02 08:32:04.557978347 +0200
@@ -1379,10 +1379,10 @@ int cifs_close(struct inode *inode, stru
                dclose = kmalloc(sizeof(struct cifs_deferred_close), GFP_KERNEL);
                if ((cfile->status_file_deleted == false) &&
                    (smb2_can_defer_close(inode, dclose))) {
-                       if (test_and_clear_bit(NETFS_ICTX_MODIFIED_ATTR, &cinode->netfs.flags)) {
-                               inode_set_mtime_to_ts(inode,
-                                                     inode_set_ctime_current(inode));
-                       }
+                       //if (test_and_clear_bit(NETFS_ICTX_MODIFIED_ATTR, &cinode->netfs.flags)) {
+                       //      inode_set_mtime_to_ts(inode,
+                       //                            inode_set_ctime_current(inode));
+                       //}
                        spin_lock(&cinode->deferred_lock);
                        cifs_add_deferred_close(cfile, dclose);
                        if (cfile->deferred_close_scheduled &&

##########

Re: [Samba] delayed mtime updates: configurable?

[Ralph Boehme]

[-- Attachment #1.1: Type: text/plain, Size: 823 bytes --]

On 8/2/25 10:31 AM, hede wrote:
> On Fri, 1 Aug 2025 18:23:22 +0200 Ralph Boehme via samba
> <samba@lists.samba.org> wrote:
> 
>> it does it once, before the write. Unfortunately that means sticky
>> mtime is in effect which means the time explicitly set is "sticky"
>> and any subsequent write must not update the mtime but the
>> explicitly set mtime must be preserved.
> 
> What I can observe here is, the time "preserved" on server side, for
> the file in the file system on disk, before the final close happens,
> seems to be some file creation time. None of the client timestamps.
> The client-sent "sticky" time then seems to get applied only in the
> end, after the final close.

hm, no idea, this should not be the case. Sorry, but I don't have the 
required day or two to do a full RCA.

-slow

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]