GNU bug report logs - #10349
tail: fix --follow on FhGFS remote file systems

Previous Next

Full log

Message #40 received at 10349 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 10349 <at> debbugs.gnu.org, Sven Breuner <sven.breuner <at> itwm.fraunhofer.de>,
	Eric Paris <eparis <at> redhat.com>, Alan Curry <pacman-cu <at> kosh.dhis.org>,
	Bob Proulx <bob <at> proulx.com>
Subject: Re: bug#10349: tail: fix --follow on FhGFS remote file systems
Date: Fri, 23 Dec 2011 15:03:22 +0100

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.

>> [*] It's easy to record local/remote in a table from which a switch stmt
>> or gperf table is derived, just as is currently done for FS magic numbers.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.