From: Sang-Heon Jeon <ekffu200098@gmail.com>
To: sfrench@samba.org
Cc: linux-cifs@vger.kernel.org, Sang-Heon Jeon <ekffu200098@gmail.com>
Subject: [RFC PATCH 0/2] smb: client: support directory change tracking
Date: Tue, 16 Sep 2025 22:34:35 +0900 [thread overview]
Message-ID: <20250916133437.713064-1-ekffu200098@gmail.com> (raw)
Hello, Steve
This RFC patch series implements directory change tracking logic for the
SMB2+ client using the SMB2 Change Notify protocol. When directory
monitoring is needed, we send a Change Notify request that remains
pending on the server until changes occur. When the server responds with
change events, we convert responds to fsnotify event and broadcast them.
If the connections is disrupted, we stop tracking and resume after
reconnection completes. Also, we stop tracking when unmount occurs.
Cleanup workers run periodically to free tracking structures for
directories that are no longer being watched.
This feature is related to f-section of TODO kernel docs.
Points for discussion:
1. This feature generates additional request/response traffic between
server and client. Is the overhead is acceptable?
2. The cleanup worker's working period is proper? Should this interval
be configurable?
3. Should we add a mount option to control this feature at mount time
rather than only having a compile-time CONFIG option? Or maybe apply
both?
4. Are there any potential of user-space breaking? Or other
vulnerability.
Future improvements:
1. More sophisticated approach to when tracking should
start/resume/stop to reduce unnecessary calls and checks.
2. improvementse Change Notify response process with various error code
and scenarios.
Basic functionality testing was performed on Ubuntu desktop with this
patchset applied, against both Windows 10 Home Server and RPI3 Samba
server environments. Also, Edge case testing may be insufficient, and I
would appreciate any help with additional test scenarios if possible.
My approach may be incorrect or incomplete in places. Please let me know
about thest issues without blame - I'm eager to learn and apply better
methods.
Thank you for taking your valuable time to review this work.
Best Regrads,
Sang-Heon Jeon
Sang-Heon Jeon (2):
smb: client: export SMB2_notify_init for directory change tracking
smb: client: add directory change tracking via SMB2 Change Notify
fs/smb/client/Kconfig | 17 ++
fs/smb/client/Makefile | 2 +
fs/smb/client/connect.c | 6 +
fs/smb/client/notify.c | 528 ++++++++++++++++++++++++++++++++++++++
fs/smb/client/notify.h | 19 ++
fs/smb/client/readdir.c | 9 +
fs/smb/client/smb2pdu.c | 8 +-
fs/smb/client/smb2proto.h | 4 +
8 files changed, 592 insertions(+), 1 deletion(-)
create mode 100644 fs/smb/client/notify.c
create mode 100644 fs/smb/client/notify.h
--
2.43.0
next reply other threads:[~2025-09-16 13:35 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-16 13:34 Sang-Heon Jeon [this message]
2025-09-16 13:34 ` [RFC PATCH 1/2] smb: client: export SMB2_notify_init for directory change tracking Sang-Heon Jeon
2025-09-16 13:34 ` [RFC PATCH 2/2] smb: client: add directory change tracking via SMB2 Change Notify Sang-Heon Jeon
2025-09-27 1:03 ` Sang-Heon Jeon
2025-09-27 8:39 ` Amir Goldstein
2025-09-29 16:51 ` Sang-Heon Jeon
2025-09-29 17:06 ` Amir Goldstein
2025-10-17 4:05 ` Sang-Heon Jeon
2025-10-23 15:30 ` Amir Goldstein
2025-10-28 16:13 ` Sang-Heon Jeon
2025-10-29 12:39 ` Amir Goldstein
2025-10-29 17:13 ` Sang-Heon Jeon
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=20250916133437.713064-1-ekffu200098@gmail.com \
--to=ekffu200098@gmail.com \
--cc=linux-cifs@vger.kernel.org \
--cc=sfrench@samba.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 read-only IMAP folder(s) and NNTP newsgroup(s).