m...@netbsd.org (Emmanuel Dreyfus) writes: >The filesystem will never recover. As I understand, this happens because >some socket has pending data that is never readen. Do I have a way to >discover what socket is holding buffer space? And is there a way to see how >much buffer space is allocated and how much remain, by the way?
netstat -m will show you how many buffers are allocated. vmstat -m will show you the parameters of the mbpool_cache ("mbpl"). A kernel with option MBUFTRACE lets netstat -mssv report finer details on mbuf usage. Unfortunately not on a per-socket level. Each socket will allocate net.inet.{udp,tcp}.{sendspace,recvspace} unless the application asks for a specific size. In -current we have buffer autosizing specified by net.inet.{udp,tcp}.{sendbuf,recvbuf}_inc and net.inet.{udp,tcp}.{sendbuf,recvbuf}_max. But I don't know a way to query the buffer size from the outside short of gdb. ENOBUFS is also reported when the sending buffer of a (SOCK_DGRAM only?) socket is full. netstat shows send-q and recv-q, not the buffer sizes but the corresponding buffer usages that give a hint what socket is sending. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."