GNU bug report logs - #14251
coreutils-8.15: tail.c : Need support for StorNext file system as distributed file system

Previous Next

Full log

Message #10 received at 14251-done <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Guenter Ressel-Herbert <Guenter.Ressel-Herbert <at> quantum.com>
Cc: 14251-done <at> debbugs.gnu.org
Subject: Re: bug#14251: coreutils-8.15: tail.c : Need support for StorNext
	file system as distributed file system
Date: Wed, 24 Apr 2013 23:08:20 +0100

[Message part 1 (text/plain, inline)]

On 04/24/2013 07:47 AM, Guenter Ressel-Herbert wrote:
> Folks,
> 
> my name is Guenter Ressel-Herbert and I'm working in Quantum's StorNext Sustaining Engineering team.
> I have a customer that needs support for tail -f on our StorNext SAN clients. StorNext (ex cvfs) is a distributed
> file system that is bypassing the VFS layer on the client, hence no trigger for any inotify registration. Seems to
> be a common issue for most distributed file systems. Checking out coreutils-8.15/src/tail.c, I found that
> tail -f reverts back to the traditional polling method for all FS's listed in  src/fs-is-local.h  returning 0. Would
> you please be so kind and add StorNext as distributed file system to that header file? You also might need
> to make up a new #define for the StorNext magic listed below.
> 
> StorNext output for fstatfs:
> 
> fstatfs(3, {f_type=0xbeefdead, f_bsize=4096, f_blocks=244187136, f_bfree=242457823, f_bavail=242457823, f_files=1262592, f_ffree=1262483, f_fsid={1939504002, 317934}, f_namelen=255, f_frsize=4096}) = 0
> 
> As you see, the magic is 0xbeefdead.

While I'm slightly hesitant above adding support for
this closed source file system, there is precedence,
and I see the clients are GPL.

So I propose to support this with the attached.

thanks,
Pádraig.

[snfs.patch (text/x-patch, attachment)]

Previous Next

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