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.
_______________________________________________
Bug-coreutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
