On Wed, 2020-08-05 at 09:43 +0200, Miklos Szeredi wrote: > On Wed, Aug 5, 2020 at 3:54 AM Ian Kent <raven@xxxxxxxxxx> wrote: > > > > It's way more useful to have these in the notification than > > > > obtainable > > > > via fsinfo() IMHO. > > > > > > What is it useful for? > > > > Only to verify that you have seen all the notifications. > > > > If you have to grab that info with a separate call then the count > > isn't necessarily consistent because other notifications can occur > > while you grab it. > > No, no no. The watch queue will signal an overflow, without any > additional overhead for the normal case. If you think of this as a > protocol stack, then the overflow detection happens on the transport > layer, instead of the application layer. The application layer is > responsible for restoring state in case of a transport layer error, > but detection of that error is not the responsibility of the > application layer. I can see in the kernel code that an error is returned if the message buffer is full when trying to add a message, I just can't see where to get it in the libmount code. That's not really a communication protocol problem. Still I need to work out how to detect it, maybe it is seen by the code in libmount already and I simply can't see what I need to do to recognise it ... So I'm stuck wanting to verify I have got everything that was sent and am having trouble moving on from that. Ian
