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

Previous Next

Full log

View this message in rfc822 format

From: Pádraig Brady <P <at> draigBrady.com>
To: Jim Meyering <jim <at> meyering.net>
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: bug#10349: tail: fix --follow on FhGFS remote file systems
Date: Fri, 23 Dec 2011 13:55:20 +0000

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() ?

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

> [*] 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.

cheers,
Pádraig.

Previous Next

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