Re: inotify back end for tail -f on linux

[Jim Meyering]

Pádraig Brady wrote:
> Jim Meyering wrote:
>> diff --git a/NEWS b/NEWS
>> index d7695e4..754f9e2 100644
>> --- a/NEWS
>> +++ b/NEWS
>> @@ -28,6 +28,8 @@ GNU coreutils NEWS                                    -*- 
>> outline -*-
>>    sort accepts a new option, --human-numeric-sort (-h): sort numbers
>>    while honoring human readable suffixes like KiB and MB etc.
>>
>> +  tail uses inotify when possible.
>> +
>>
>
> That's a little terse. How about:
>
> tail --follow uses inotify when possible to be more responsive
> to file changes and also be more scalable when many files are monitored.

Sure.  Mentioning improved responsiveness is better.
What do you mean by "more scalable"?
It's currently still subject to the limit on number
of open file descriptors, which is tied to the number
of tailed files.

...
>> +          if (wd < 0)
>> +            error (0, errno, _("inotify cannot be used, reverting to 
>> polling"));
>
> Do we need to warn here since the fallback is functionally equivalent?
> It's OK if the error is rare, but I'm worried that errors might be issued
> from /sys or /proc or if the user boots an old kernel, or whatever.
> Well not that worried TBH, just mentioning it :)

If I'm using tail -f on a system that *should* support the inotify-enabled
code, I want to know right away (and why, hence "errno") if that fails.

Otherwise, we'd have to wait for someone to notice the degraded
performance and to debug it to determine why it reverted to the old method.