<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 23, 2021 at 3:35 AM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 6/22/21 7:33 PM, enh via Toybox wrote:<br>
> "how hard can `tail -F` be?" i thought ... but unless i'm using inotify wrong,<br>
> the answer turns out to be "quite a lot harder than i expected because i need<br>
> watch the parent directory for a different set of events, and then filter those".<br>
<br>
Never used it before,<br></blockquote><div><br></div><div>me neither. apparently testy folks ... no, that's not the right word :-) ... *QA* folks like to rotate logs, and doing that breaks `tail -f` like the rest of us use.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> strace tells me that coreutils actually does use inotify, whereas busybox just<br>
> polls (by sleeping). would you be happy (at least for the time being) with a<br>
> crappy polling `tail -F`?<br>
<br>
Sure.<br>
<br>
It's not even that crappy, how much response time granularity do you want?<br>
(Dunno the expected use case, if it's humans 1/second is plenty, "watch"<br>
defaults to every 2 seconds, any "less" implementation dumb enough to listen to<br>
posix is batching same-line output frustratingly. In theory inotify on the<br>
directory can wake up _more_ often if it's an active enough directory. Whatever<br>
you do, a file that's rapidly created and deleted again can be missed by another<br>
process, And if your tail -c output size is finite then a file that starts with<br>
a large enough atomic write will make tail skip data...<br>
<br>
I remember Linus once said on linux-kernel that Linux won't split a write()<br>
going to a "local" filesystem, by which I assume he meant "block backed" in the<br>
block/pipe/ram/synth categories from <a href="http://landley.net/toybox/doc/mount.txt" rel="noreferrer" target="_blank">http://landley.net/toybox/doc/mount.txt</a> .<br>
(Presumably ram backed is in there too. Pipe backed filesystems are only atomic<br>
to PIPE_BUF, which includes network filesystems, and synthetic filesystems can<br>
do anything the driver cares to implement including gratuitously short writes.)<br>
<br>
But block backed filesystems won't unless they fill up, so a 1 gigabyte write()<br>
atomically updating the file length is a real possibility. Note that Mac at one<br>
time did _not_ handle atomicity even to the level posix requires (the write()<br>
can be shorter than requested by what DOES get accepted, everybody sees the same<br>
thing at the same time):<br>
<br>
<a href="https://stackoverflow.com/questions/10650861/atomicity-of-write2-to-a-local-filesystem" rel="noreferrer" target="_blank">https://stackoverflow.com/questions/10650861/atomicity-of-write2-to-a-local-filesystem</a><br>
<br>
Anyway: yay polling implemenation of -F.<br></blockquote><div><br></div><div>cool! meetings ate today, but i have high hopes for tomorrow (and an implementation from someone else that's probably fine)...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> i can guarantee i can find the time to do that...<br>
> rewriting the inotify stuff to support deletion/re-creation keeps failing to fit<br>
> into any available time gap (and then i have the "where was i?" problem that i<br>
> know you're all too familiar with!).<br>
<br>
Oh yeah. I refer to it as swap thrashing. Scheduler overhead and faulting data<br>
back in eats your time slice.<br></blockquote><div><br></div><div>(speaking of which, although it sounds like a terrible self-help book, i actually quite enjoyed "Algorithms to Live By: The Computer Science of Human Decisions". i don't think i've read a pop-sci book on CS before! anyway, yeah, they tried to introduce the term "thrashing" [in our sense] to the general population...)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Rob<br>
</blockquote></div></div>