TrueNAS 13 and kernel change notify = No

[scottrus71]

I see in the /usr/local/etc/smb4.conf that the default of kernel change notify = No is set. When left as "No", changes made via NFS on Linux do not show up on MacOS clients connected via CIFS. If I switch this to "Yes", the problem is resolved.

There is an older thread https://www.truenas.com/community/threads/kernel-change-notify-yes.45379/ saying FreeBSD 9.2.1.3 had issues with this. Anyone know if this is still an issue on 13.1-RELEASE-p7?

 

[sretalla]

I would suggest using the Report a Bug link to raise this (maybe search on Jira for it while you're there in case somebody is already working on it).

 

[anodos]

This is a matter of how kqueue / libinotify shim is designed. If you need kernel change notifications, you should use SCALE.

 

[scottrus71]

Thanks. I opened https://ixsystems.atlassian.net/browse/NAS-124241.

 

[scottrus71]

This is a matter of how kqueue / libinotify shim is designed. If you need kernel change notifications, you should use SCALE.

I don't need this setting. I need a solution that meets expectations of MacOS SMB clients seeing changes from Linux NFS clients without having to manually refresh the share in MacOS. For user shares across environments that's kind of a base expectation.

 

[anodos]

I don't need this setting. I need a solution that meets expectations of MacOS SMB clients seeing changes from Linux NFS clients without having to manually refresh the share in MacOS. For user shares across environments that's kind of a base expectation.

Multi-protocol shares in Core / Enterprise are couched in certain caveats like this (which is somewhat the tip of the iceberg). The Linux SMB client is generally quite good, and so the generally supported / recommended way of managing storage access in multi-OS environments is to just use SMB.

If you need this other feature, use SCALE where file change notifications are implemented in a different manner. We generally won't introduce massive kernel changes (with risk of regression) into the stable enterprise product for edge case configurations that are addressed in a separate product.

 

[scottrus71]

Multi-protocol shares in Core / Enterprise are couched in certain caveats like this (which is somewhat the tip of the iceberg). The Linux SMB client is generally quite good, and so the generally supported / recommended way of managing storage access in multi-OS environments is to just use SMB

We can look in to this. Our first experience was that NFS was performing better than SMB on Ubuntu Linux but there may be more tuning to be done.

If you need this other feature, use SCALE where file change notifications are implemented in a different manner.

SCALE is still maturing. It's something to consider in the future.

We generally won't introduce massive kernel changes (with risk of regression) into the stable enterprise product for edge case configurations that are addressed in a separate product.

Of course. Expectation is the behavior works as expected, not to use a specific setting to achieve it. It's only a bug if the use case cannot be solved without setting Kernel change notify = Yes. For mixed NFS / SMB environments, I think you are confirming that yes, this bug still exists in FreeBSD 13? Is that verified? And while there is no fix for NFS / SMB mixed environments, the work around is to use only SMB?

 

[Patrick M. Hausen]

Or NFS read-only

I actually do this. SMB to manage my media library, NFS read-only export for the devices that play it (Apple TV etc.)

 

[anodos]

Or NFS read-only

I actually do this. SMB to manage my media library, NFS read-only export for the devices that play it (Apple TV etc.)

Right. That's another option.

Expectation is the behavior works as expected, not to use a specific setting to achieve it. It's only a bug if the use case cannot be solved without setting Kernel change notify = Yes. For mixed NFS / SMB environments, I think you are confirming that yes, this bug still exists in FreeBSD 13? Is that verified? And while there is no fix for NFS / SMB mixed environments, the work around is to use only SMB?

It's not a bug in FreeBSD 13. It's a known limitation for libinotify implementation on the platform. Enabling plumbing for SMB notification requests to libinotify requests on the platform can lead to exhaustion of open files, which would lead to prod-down on the server. This is not suitable for production workloads full-stop.

SCALE is still maturing. It's something to consider in the future.

For basic NAS services I don't see a problem with SCALE (as long as you aren't trying to run a pre-release version).

 

[scottrus71]

Okay, understood. The summary I’m hearing is

1. TrueNAS Core 13 does not offer realtime SMB share updates in mixed use NFS / SMB envionrments. This is due to limitations at the OS level with FreeBSD.
2. There are work arounds proposed for the limitation:
   1. Use SMB everywhere
   2. In mixed NFS / SMB environments, eliminate changes from non-SMB clients. (Eg, read-only NFS shares)
   3. Use TrueNAS SCALE which supports Kernel change notify = Yes

I really appreciate all the support and follow ups. The community has been a great resource as I dive in TrueNAS.

 

[anodos]

Okay, understood. The summary I’m hearing is

1. TrueNAS Core 13 does not offer realtime SMB share updates in mixed use NFS / SMB envionrments. This is due to limitations at the OS level with FreeBSD.
2. There are work arounds proposed for the limitation:
   1. Use SMB everywhere
   2. In mixed NFS / SMB environments, eliminate changes from non-SMB clients. (Eg, read-only NFS shares)
   3. Use TrueNAS SCALE which supports Kernel change notify = Yes

I really appreciate all the support and follow ups. The community has been a great resource as I dive in TrueNAS.

Or use a better client that has the ability to refresh directory listings :)