NFS "UDP Client" missing

duartelazaro

Cadet
Joined
Mar 18, 2024
Messages
3
Hi to all,

i upgraded from truenas core to truenas scale 10.23.2.

i have a legacy equipment that requires UDP communication, and on Core i was able to set the configuration "Serve UDP Clients" to true... whitch changed the "udp=y" on the config file.

I cannot find that on truenas scale 23.10.2.

Any info how can i set that config ?

Thanks in advanced
 

Kris Moore

SVP of Engineering
Administrator
Moderator
iXsystems
Joined
Nov 12, 2015
Messages
1,471
I don't think we exposed that option, first request we've heard for it. You may want to toss us a ticket and we'll see if that can be exposed again.

In the meantime, I'm curious, how old are these clients anyway? :)
 

duartelazaro

Cadet
Joined
Mar 18, 2024
Messages
3
I don't think we exposed that option, first request we've heard for it. You may want to toss us a ticket and we'll see if that can be exposed again.

In the meantime, I'm curious, how old are these clients anyway? :)
Hi thanks for getting back.
it is a hikvision DVR (DS-7208HQHI-K1), it stores CCTV media.
:(
 

duartelazaro

Cadet
Joined
Mar 18, 2024
Messages
3
We did some checking, UDP is disabled on Linux side for good reason, can lead to corruption:

Hi,
So this means that i need to upgade my HDR CCTV device o find another NFS distro that has the feature enabled or stick to TRUENAS CORE.

It works on TrueNAS Core -13.0-U6.1 only on TRUENAS SCALE the option is not available on the GUI.

I was able to find the nfs config file on TrueNAS Scale on (/etc...nfs.conf.d/local.conf)... but when i change the config and restart the service the config is rewritten (i think its a feature on TrueNAS to guarantee that changes are just on the GUI).

So although i see understand the change on the kernel, itś not actually deprecated on the TrueNAS distro... it is just not visible on SCALE.

Any thoughts on how to stick the configuration to the nfs.../local.conf ?

Thanks
 

Arwen

MVP
Joined
May 17, 2014
Messages
3,611
There are lots of unsupported programs or features on TrueNAS SCALE or Core. Part of the problem is that iX has to make their product suitable, (like data integrity), for the Enterprise. Having the ability to re-enable a known data corruption issue is probably not something they want to do.

That said, their are lots of unsupported methods to enable such. Some may break after update and require re-work. Others may break permanently on update, and require a different approach.

One unsupported method is to implement a post boot script. I don't remember where that is in the GUI. But, you create a script that makes the configuration file change, restarts the NFS service and you are good to go for the moment.

Now is this an ideal approach?
Probably not. It might be better to make a VM that supports NFS over UDP, and has access to the proper storage pool.

Note to all reading this, the out of order & fragmentation issue with UDP may not be a problem with a HDR CCTV device because it may be limited to 10/100Mbit/ps Ethernet with stock 1500 MTU. The out of order & fragmentation issue for UDP packets is a problem when using higher speed network, multiple routers, or links with different MTU, (Maximum Transfer Unit), sizes.
 

Kris Moore

SVP of Engineering
Administrator
Moderator
iXsystems
Joined
Nov 12, 2015
Messages
1,471
I couldn't have said it better. Any time there is a potential for data loss, we will go out of our way to not expose that "feature", since above all else we have to be about protecting data integrity. Setting up a custom VM or "jump host" like that might make more sense for this very unique use-case.
 
Joined
Oct 22, 2019
Messages
3,641
I'm still trying to understand why this approach cannot work. Everyone wins, and iX does not compromise data integrity.

Because as it stands now, a user who wants to do this anyways has to jump through a more convoluted hoop. The above method simply gives them an option that works with the GUI's/middleware's persistent config. (Meanwhile, no one else is affected, since the default safeguard is in place.)
 

Kris Moore

SVP of Engineering
Administrator
Moderator
iXsystems
Joined
Nov 12, 2015
Messages
1,471
The aux param functionality brings its own challenges. Specifically since we don't map them, on upgrades they are very error prone to flat out causing breakages, or worse yet, some new undefined behavior that surprises the user. We tightened that up on purpose because of the alarmingly high number of folks reporting failures because they had copy-n-pasted something they read on a forum post from years back and ended up horking their shares in "fun" new ways.

But generally agreed, it would be nice to have a better way for overrides like this to be handled, if we can come up with an elegant solution.
 
Joined
Oct 22, 2019
Messages
3,641
That's the user's own responsibility, though. I'll even support iX shutting down bug reports at the first hint that an auxiliary parameter was used, without spending a single minute on any such bug reports.

  • iXsystems isn't preventing users from installing TrueNAS on a rubbish, underpowered system with cheap "SATA multipliers".
  • It's not restricting TrueNAS's installation on a virtual machine, without truly understanding the requirements.
  • It doesn't outright prevent users from creating a pool comprised of single-drive striped vdevs.
  • It doesn't prevent users from enabling dedup, which has been a source of "after-the-fact" regret for many.
  • It doesn't deny destructive commands in the shell (on SCALE), where it's very easy to destroy your data.
  • Etc...

All of the above can ruin TrueNAS's "brand", put users' data at risk, and cause negative experiences.

I understand having "safe defaults" and "hiding options" that require a user going out of their way to acknowledge the SERIOUS DISCLAIMER before they continue. But to simply outright remove their ability to do so? It's going too far in the other direction.
 
Top