Subject: bug#14251: closed (Re: bug#14251: coreutils-8.15: tail.c : Need support for StorNext file system as distributed file system)

From: [email-masked] (GNU bug Tracking System)
Date: Wed, 24 Apr 2013 22:14:02 +0000

Your bug report

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

which was filed against the coreutils package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
14251: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14251
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#14251: coreutils-8.15: tail.c : Need support for StorNext file system as distributed file system
From: Pádraig Brady <[email-masked]>
To: Guenter Ressel-Herbert <[email-masked]>
Cc: [email-masked]
Date: Wed, 24 Apr 2013 23:08:20 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

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.

>From fc03e111bf9d5265436246a258898ce3e0e6b8a7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= <[email-masked]>
Date: Wed, 24 Apr 2013 22:59:46 +0100
Subject: [PATCH] stat,tail: improve support for snfs

The StorNext distributed file system was previously known as CVFS.

* src/stat.c (human_fstype): Add new file system ID definition.
* NEWS: Mention the improvement.
Fixes http://bugs.gnu.org/14251
---
 NEWS       |    2 +-
 src/stat.c |    2 ++
 2 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/NEWS b/NEWS
index fc05b8a..3edb946 100644
--- a/NEWS
+++ b/NEWS
@@ -32,7 +32,7 @@ GNU coreutils NEWS                                    -*- outline -*-
 
 ** Improvements
 
-  stat and tail work better with EFIVARFS, EXOFS, F2FS and UBIFS.
+  stat and tail work better with EFIVARFS, EXOFS, F2FS, SNFS and UBIFS.
   stat -f --format=%T now reports the file system type, and tail -f now uses
   inotify for files on those file systems, rather than the default (for unknown
   file system types) of issuing a warning and reverting to polling.
diff --git a/src/stat.c b/src/stat.c
index 8ba958a..a1d558c 100644
--- a/src/stat.c
+++ b/src/stat.c
@@ -399,6 +399,8 @@ human_fstype (STRUCT_STATVFS const *statfsbuf)
       return "selinux";
     case S_MAGIC_SMB: /* 0x517B remote */
       return "smb";
+    case S_MAGIC_SNFS: /* 0xBEEFDEAD remote */
+      return "snfs";
     case S_MAGIC_SOCKFS: /* 0x534F434B local */
       return "sockfs";
     case S_MAGIC_SQUASHFS: /* 0x73717368 local */
-- 
1.7.7.6

Subject: coreutils-8.15: tail.c : Need support for StorNext file system as distributed file system
From: Guenter Ressel-Herbert <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: Guenter Ressel-Herbert <[email-masked]>
Date: Wed, 24 Apr 2013 06:47:19 +0000
List-Id: <debbugs-submit.debbugs.gnu.org>

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.

Thanks a lot!

Guenter Ressel-Herbert

----------------------------------------------------------------------
The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.