Re: inotify back end for tail -f on linux

[Pádraig Brady]

Jim Meyering wrote:
> 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.

Well I was thinking it would be more efficient than polling
as the number of files monitored was increased. How about:

tail --follow now uses inotify when possible, to be more responsive
to file changes and also be more efficient when many files are monitored.

>>> +          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.

Cool. Just ensuring it was considered.

cheers,
Pádraig.