MFC 259339

    sbin/devd/devd.cc
        Increase the size of devd's client socket's send buffer from the
        default (8k) to 128k.  This prevents clients from getting
        POLLHUPped during event storms.  For example, during zpool creation,
        the kernel emits a resource.fs.zfs.statechange event for every vdev
        in the pool.  A 128k buffer is large enough to hold the statechange
        events for a pool with nearly 800 drives.

MFC 259362
    sbin/devd/devd.cc
        Promoting the SIGINFO handler's log message from LOG_INFO to
        LOG_NOTICE, and promoting the "Processing event ..." message from
        LOG_DEBUG to LOG_INFO.  Setting the logfile to LOG_NOTICE with this
        change will have the same result as setting it to LOG_INFO without
        this change.  Setting it to LOG_INFO with this change will include
        the useful "Processing event ..." messages that were previously at
        LOG_DEBUG, without including useless messages like "Pushing table".

        The intent of this change is that one can log "Processing event ..."
        without logging "Pushing table" and related messages that are sent
        for every event.  The number of lines actually logged is reduced by
        about 75% by making this change and setting syslog to LOG_INFO vs
        setting syslog to LOG_DEBUG.

    etc/syslog.conf
        Changing the recommended loglevel to notice instead of info.

1 files changed, 22 insertions, 3 deletions

diff --git a/sbin/devd/devd.cc b/sbin/devd/devd.cc
index 447ab87..cdeadf9 100644
--- a/sbin/devd/devd.cc
+++ b/sbin/devd/devd.cc
@@ -104,6 +104,19 @@ __FBSDID("$FreeBSD$");
 #define CF "/etc/devd.conf"
 #define SYSCTL "hw.bus.devctl_disable"
 
+/*
+ * Since the client socket is nonblocking, we must increase its send buffer to
+ * handle brief event storms.  On FreeBSD, AF_UNIX sockets don't have a receive
+ * buffer, so the client can't increate the buffersize by itself.
+ *
+ * For example, when creating a ZFS pool, devd emits one 165 character
+ * resource.fs.zfs.statechange message for each vdev in the pool.  A 64k
+ * buffer has enough space for almost 400 drives, which would be very large but
+ * not impossibly large pool.  A 128k buffer has enough space for 794 drives,
+ * which is more than can fit in a rack with modern technology.
+ */
+#define CLIENT_BUFSIZE 131072
+
 using namespace std;
 
 extern FILE *yyin;
@@ -759,7 +772,7 @@ process_event(char *buffer)
 	char *sp;
 
 	sp = buffer + 1;
-	devdlog(LOG_DEBUG, "Processing event '%s'\n", buffer);
+	devdlog(LOG_INFO, "Processing event '%s'\n", buffer);
 	type = *buffer++;
 	cfg.push_var_table();
 	// No match doesn't have a device, and the format is a little
@@ -892,6 +905,7 @@ void
 new_client(int fd)
 {
 	int s;
+	int sndbuf_size;
 
 	/*
 	 * First go reap any zombie clients, then accept the connection, and
@@ -901,10 +915,15 @@ new_client(int fd)
 	check_clients();
 	s = accept(fd, NULL, NULL);
 	if (s != -1) {
+		sndbuf_size = CLIENT_BUFSIZE;
+		if (setsockopt(s, SOL_SOCKET, SO_SNDBUF, &sndbuf_size,
+		    sizeof(sndbuf_size)))
+			err(1, "setsockopt");
 		shutdown(s, SHUT_RD);
 		clients.push_back(s);
 		++num_clients;
-	}
+	} else
+		err(1, "accept");
 }
 
 static void
@@ -970,7 +989,7 @@ event_loop(void)
 		}
 		rv = select(max_fd, &fds, NULL, NULL, &tv);
 		if (got_siginfo) {
-			devdlog(LOG_INFO, "Events received so far=%u\n",
+			devdlog(LOG_NOTICE, "Events received so far=%u\n",
 			    total_events);
 			got_siginfo = 0;
 		}