From: ronnie sahlberg <ronniesahlberg@gmail.com>
To: linux-cifs <linux-cifs@vger.kernel.org>
Subject: Oddity: When should Mtime and Ctime be updated for SMB servers?
Date: Fri, 6 Sep 2019 08:59:51 +1000 [thread overview]
Message-ID: <CAN05THTazV4oLs+yq5SR1RYDO2p1VVmN7qnb=KBkfmZEpx8E0A@mail.gmail.com> (raw)
List, All,
I was trying to investigate why we had a regression in xfstests
generic/313 and found something odd about when Windows updates the
timestamps for a file.
What the test performs is basically:
1, Create a file
2, Set file size to 0
3, explicitly set the ctime and mtime to the current time of the client
4, read the timestamps back and verify they are set correctly
delay for 1 second
5, write to the file
6, truncate the file back to 0
7, and check the timestamps again, they should have been updated due to 5,6
This works as expected IF step 3 uses a compound, i.e. a different
handle (how cifs.ko used to work, since this particular kernel api is
path based)
However, IF step 3 uses the same handle from step 1 instead of a
compound then this no longer works. The timestamps are no longer
updated in steps 5,6.
What are the semantics for when these timestamps should be updated by
a write or a truncate?
And why does it matter if step 4 is a compound with
create/setinfo/close versus if it just uses the same handle from the
create in step 1?
Since the traces are tiny I will include them in ASCII form. Anyone
that wants the actual pcap traces to view them in wireshark, just
email me and I will send them.
Original cifs.ko behavior:
====================
1 0.000000000 SMB2 Create Request File: bar
2 0.001809747 SMB2 Create Response File: bar
8 0.004397925 SMB2 Flush Request File: bar
9 0.013682200 SMB2 Flush Response
11 0.014561091 SMB2 SetInfo Request
FILE_INFO/SMB2_FILE_ENDOFFILE_INFO File: bar
12 0.014957578 SMB2 SetInfo Response
14 0.015851218 SMB2 Create Request File: bar;SetInfo Request
FILE_INFO/SMB2_FILE_BASIC_INFO;Close Request
15 0.016358273 SMB2 Create Response File: bar;SetInfo Response;Close Response
17 0.017253133 SMB2 Create Request File: bar;GetInfo Request
FILE_INFO/SMB2_FILE_ALL_INFO;Close Request
18 0.017736416 SMB2 Create Response File: bar;GetInfo Response;Close Response
20 1.019048674 SMB2 Write Request Len:22 Off:0 File: bar
21 1.020140390 SMB2 Write Response
23 1.021696732 SMB2 SetInfo Request
FILE_INFO/SMB2_FILE_ENDOFFILE_INFO File: bar
24 1.022446473 SMB2 SetInfo Response
26 1.024223917 SMB2 Create Request File: bar;GetInfo Request
FILE_INFO/SMB2_FILE_ALL_INFO;Close Request
27 1.025163155 SMB2 Create Response File: bar;GetInfo Response;Close Response
29 1.028479545 SMB2 Close Request File: bar
30 1.029246502 SMB2 Close Response
In this case, packet 14 is the compound used to set the timestamps.
Packet 17 reports that the timestamps were set to the values in 14.
Now there is a one second delay and we write to the file, truncate it
and then read back the timestamps and the timestamps have incremented.
New cifs.ko behavior:
=================
4 0.003062951 SMB2 Create Request File: bar
5 0.004362998 SMB2 Create Response File: bar
7 0.005922755 SMB2 Flush Request File: bar
8 0.009779700 SMB2 Flush Response
10 0.011293505 SMB2 SetInfo Request
FILE_INFO/SMB2_FILE_ENDOFFILE_INFO File: bar
11 0.012076033 SMB2 SetInfo Response
12 0.013181837 SMB2 SetInfo Request FILE_INFO/SMB2_FILE_BASIC_INFO File: bar
13 0.014015512 SMB2 SetInfo Response
14 0.015743571 SMB2 Create Request File: bar;GetInfo Request
FILE_INFO/SMB2_FILE_ALL_INFO;Close Request
15 0.016904597 SMB2 Create Response File: bar;GetInfo Response;Close Response
17 1.018801828 SMB2 Write Request Len:22 Off:0 File: bar
18 1.019773131 SMB2 Write Response
20 1.021448036 SMB2 SetInfo Request
FILE_INFO/SMB2_FILE_ENDOFFILE_INFO File: bar
21 1.022202409 SMB2 SetInfo Response
23 1.023990091 SMB2 Create Request File: bar;GetInfo Request
FILE_INFO/SMB2_FILE_ALL_INFO;Close Request
24 1.025077567 SMB2 Create Response File: bar;GetInfo Response;Close Response
26 1.028801682 SMB2 Close Request File: bar
27 1.029697708 SMB2 Close Response
The only difference here is that in packet 12, where we set the
timestamps, we no longer use a new handle in a c reate/setinfo/close
compound but instead
use the existing handle that is already open.
In this case the timestamps are no longer updated by the write or
truncate in packets 17 and 20.
Regards
Ronnie Sahlberg
reply other threads:[~2019-09-05 23:00 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAN05THTazV4oLs+yq5SR1RYDO2p1VVmN7qnb=KBkfmZEpx8E0A@mail.gmail.com' \
--to=ronniesahlberg@gmail.com \
--cc=linux-cifs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).