- User Since
- Nov 14 2014, 6:00 AM (362 w, 6 d)
Sep 4 2021
In general, this is a definite improvement over fixed size buffers (that are actually liable to subtle overruns).
Aug 13 2021
I have been testing with this code for about a week. Other than the problem I identified in g_gatec_connect(), I haven't had any issues. I haven't specifically tried comparing protocols 0 and 1 but protocol 1 should at worst perform the same as protocol 0 and used only half the TCP connections, making it an overall win.
Aug 3 2021
My comments aside, I believe this is worth committing now. Further improvements are needed but this corrects some clear bugs that are relatively easily triggered.
Aug 1 2021
I have been experimenting with zfs send to geli on ggate and had ggatec processes die reporting "ioctl(/dev/ggctl): Cannot allocate memory." and replaced line ggatec.c:134 with the following:
Jul 27 2021
I did some experiments with ggate in late 2019 and was concerned about the lack of sanity checking - I managed to get the client system to generate a 1GiB read request, which the server choked on. From my notes at the time:
4659 ggatec CALL recvfrom(0x4,0xffffbffddf08,0x3ffbc000,0x40<MSG_WAITALL>,0,0)
4659 ggatec RET recvfrom -1 errno 14 Bad address
Unfortunately, I didn't keep a record of how I had generated that request. (And for other reasons, I lost interest in ggate at that time).
Jul 10 2021
Jul 4 2021
Unidirectional data transfer is definitely the worst case for TCP and a single bidirectional socket should work better than two unidirectional sockets whilst using less resources. That said, have you done any performance comparisons between the protocol versions with recent FreeBSD?
Jul 2 2021
(Sorry for the delay. I thought I'd responded). Then I withdraw my objections. The code itself looks good.
Jun 19 2021
I agree this is only applicable to the RK805. The patch works and provides access to the Rock64 LEDs (pin 0 is red and pin 1 is white, with the LED lit when the output is 0). On the downside, and as noted in the description, there is a LOR with led(9). I'm a bit concerned at adding known new LORs to the code. Are there any options for getting rid of the LOR other than redesigning led(9)?
Jun 17 2021
Apr 9 2021
Mar 16 2021
Update ObsoleteFiles with the deleted files.
Mar 14 2021
Rather than cleaning up a dead macro, remove a collection of dead files. This has passed a "make buildworld buildkernel" on amd64. I'm currently running a "make tinderbox"
I can't find any "amd" port. The only automounter-related ports I can find are sysutils/am-utils, sysutils/automount and sysutils/automounter, none of which seem to reference anything in nfs_common.h. It looks like sys/nfs/nfs_common.h, sys/nfsserver/nfsm_subs.h and sys/nfsclient/nfsm_subs.h are all unreferenced - I shall try another "make universe" to check.
Mar 12 2021
Mar 10 2021
Replace diff to include more context
Mar 9 2021
Added context, no changes.
Updated to account for previous comments:
There hasn't been any response by andrew to previous comments and I have a revised patch.
Since I don't seem to be able to update the patch here, I've created D29140 as a replacement that addresses all the comments above.
Mar 6 2021
Dec 27 2020
Oct 25 2019
Oct 4 2019
This patch fixes a reproduceable NFS deadlock (deadlres_td_sleep_q panic) I was getting on my diskless Rock64 with recent kernels.
May 3 2019
Apr 16 2019
Feb 10 2019
Jul 18 2018
Jul 17 2018
Jul 14 2018
Mar 26 2018
Jan 30 2017
Based on kib's comments, I'll withdraw this revision. r312984 is similar functionality.
Jan 26 2017
Jan 24 2017
Change "LOGDIR" to "UNIVERSE_LOGDIR" to reduce risk of clashes.
Jan 23 2017
Jun 27 2016
May 12 2015
I've been bitten in the past by a buffer size change causing unexpected breakage (bin/144446) and would be wary of making this change without extensive testing. The claimed benefit is improved performance - in which case, I'd expect more justification than a single md5 and sha256 test. What does ministat(1) report on 3-5 runs?