A repeated err record in the log is the newest record counted, not another line

A client retrying a write that fails the same way pushed one err line after
another until the log's ring held nothing else. The same err as the newest
record is now that record with a count, (x4), as +Messages counts repeats; a
follower that has already read the record still gets each repeat as its own
line, since it may be waiting on exactly that.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

1 files changed, 4 insertions, 1 deletions

diff --git a/docs/fs.md b/docs/fs.md
index ffb509cf..bd8ca055 100644
--- a/docs/fs.md
+++ b/docs/fs.md
@@ -335,7 +335,10 @@ includes each builtin announcing itself as it runs), and `err <serial|->
 <file>: <why>` for every write or truncation the tree refused or that
 failed -- through a mount a shell sees only the errno its kernel mapped the
 reply to, usually `Invalid argument`, and this is the reason (`err 3 addr:
-no match for regexp`). There is no per-pane error file to read instead:
+no match for regexp`). The same err again, before any follower has read
+the first, is that record counted (`err 3 addr: no match for regexp (x4)`),
+so a client retrying a failing write does not push the rest out of the
+ring; a follower that read it gets each repeat. There is no per-pane error file to read instead:
 acme's `errors` only takes text, and one record stream is simpler to watch
 than a file per pane. A `msg` said while a
 pane is being made can precede that pane's `new`; panes present at boot are