On Wed, 2020-01-22 at 14:25 -0500, Steve Dickson wrote: > FYI... > > NFS over UDP will be deprecated in the 5.6 kernel. > > https://bugzilla.redhat.com/show_bug.cgi?id=1794117 > > Its not clear what or if any havoc this could cause > but the commit (f745bfdc) has been accepted upstream. > Just letting the community know... Yeah, that's going to be a problem for am-utils. It's been a while but IIRC there was a bug that I fixed in the single-threaded concurrent mount handling that requires UDP to work properly, not to mention the completely unnecessary TCP overhead for the localhost (limited function) server of the amd daemon. It's not my doing the daemon implemented the concurrent mounting this way, it was done many years ago, I just fixed the bug I found. I also don't think re-implementing the concurrent mounting is an option and neither is converting amd to use pthreads which I think are the only ways around this. I implemented an NFSv3 server for amd when NFSv2 was dropped and while implementing an NFSv4 server might not be that all that difficult I really would rather not go there, especially since there's nothing to gain from doing it. There would need to be a decent number of am-utils package users that can demonstrate that they can't use the amd format map support now present in the Linux autofs automounter. I accept that the way autofs handles amd maps internally (necessarily) isn't the same as that of amd and amd users might not be terribly happy with it but that's the way it is. To change that would be a very significant amount of work that may or may not work in the end and will almost certainly disrupt existing functionality and still not get entirely the same behaviour. Speaking of behaviour, I mean the way mounts are performed internally not semantic behaviour, amd format maps should themselves behave as expected for the amd map features that are supported in autofs (and that's a fairly large portion of the amd functionality). Ian _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
