[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#10349: tail: fix --follow on FhGFS remote file systems
From: |
Pádraig Brady |
Subject: |
bug#10349: tail: fix --follow on FhGFS remote file systems |
Date: |
Fri, 23 Dec 2011 14:13:16 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 |
On 12/23/2011 02:03 PM, Jim Meyering wrote:
> Pádraig Brady wrote:
>> On 12/23/2011 12:08 PM, Jim Meyering wrote:
>>> Pádraig Brady wrote:
>>>> On 12/22/2011 11:48 PM, Pádraig Brady wrote:
>>>>> On 12/22/2011 09:50 PM, Alan Curry wrote:
>>>>>> Bob Proulx writes:
>>>>>>>
>>>>>>> Jim Meyering wrote:
>>>>>>>> Are there so many new remote file systems coming into use now?
>>>>>>>> That are not listed in /usr/include/linux/magic.h?
>>>>>>>
>>>>>>> The past can always be enumerated. The future is always changing. It
>>>>>>> isn't possible to have a complete list of future items. It is only
>>>>>>> possible to have a complete list of past items. The future is not yet
>>>>>>> written.
>>>>>>
>>>>>> Between past and future is the present, i.e. the currently running
>>>>>> kernel.
>>>>>> Shouldn't it return an error when you use an interface that isn't
>>>>>> implemented
>>>>>> by the underlying filesystem? Why doesn't this happen?
>>>>>
>>>>> That's a fair point.
>>>>>
>>>>> Eric shouldn't some/all remote file systems in the kernel
>>>>> return ENOTSUP for inotify operations?
>>>>
>>>> Oh right, as Sven points out,
>>>> a notification _is_ sent for local processes modifying a remote file.
>>>> I guess we'd need a IN_REMOTE flag (send remote events too), which
>>>> remote file systems would return ENOTSUP if they don't support that.
>>>> That's getting a bit awkward though.
>>>
>>> I'm thinking of recording[*] which file systems are local and which
>>> are remote.
>>
>> You mean by tagging the table in stat.c with say "(remote)" after the
>> hex constant?
>> Then use that to build a header for use by tail::fremote() ?
>
> Yes.
>
>>> Then we can make tail -f warn when one or more of
>>> its file arguments resides on a remote file system. We may finally
>>> have to add and document --disable-inotify.
>>
>> Currently we fall back to polling for remote file systems.
>> I'm not sure it's worth warning since it's only a latency difference.
>
> My original goal was to warn, for unknown file system types,
> that the type is unknown (suggesting to report it), and that
> tail -f is resorting to the use of polling.
Oh right, warn about unknown.
That would make sense.
cheers,
Pádraig.
- bug#10349: tail: fix --follow on FhGFS remote file systems, (continued)
- bug#10349: tail: fix --follow on FhGFS remote file systems, Jim Meyering, 2011/12/22
- bug#10349: tail: fix --follow on FhGFS remote file systems, Sven Breuner, 2011/12/22
- bug#10349: tail: fix --follow on FhGFS remote file systems, Bob Proulx, 2011/12/22
- bug#10349: tail: fix --follow on FhGFS remote file systems, Alan Curry, 2011/12/22
- bug#10349: tail: fix --follow on FhGFS remote file systems, Pádraig Brady, 2011/12/22
- bug#10349: tail: fix --follow on FhGFS remote file systems, Pádraig Brady, 2011/12/22
- bug#10349: tail: fix --follow on FhGFS remote file systems, Jim Meyering, 2011/12/23
- bug#10349: tail: fix --follow on FhGFS remote file systems, Pádraig Brady, 2011/12/23
- bug#10349: tail: fix --follow on FhGFS remote file systems, Jim Meyering, 2011/12/23
- bug#10349: tail: fix --follow on FhGFS remote file systems,
Pádraig Brady <=
- bug#10349: tail: fix --follow on FhGFS remote file systems, Jim Meyering, 2011/12/23
- bug#10349: tail: fix --follow on FhGFS remote file systems, Pádraig Brady, 2011/12/23
- bug#10349: tail: fix --follow on FhGFS remote file systems, Jim Meyering, 2011/12/23
- bug#10349: tail: fix --follow on FhGFS remote file systems, Sven Breuner, 2011/12/23
- bug#10349: tail: fix --follow on FhGFS remote file systems, Sven Breuner, 2011/12/22