emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#14251: closed (coreutils-8.15: tail.c : Need suppo


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#14251: closed (coreutils-8.15: tail.c : Need support for StorNext file system as distributed file system)
Date: Wed, 24 Apr 2013 22:14:02 +0000

Your message dated Wed, 24 Apr 2013 23:08:20 +0100
with message-id <address@hidden>
and subject line Re: bug#14251: coreutils-8.15: tail.c : Need support for 
StorNext file system as distributed file system
has caused the debbugs.gnu.org bug report #14251,
regarding coreutils-8.15: tail.c : Need support for StorNext file system as 
distributed file system
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
14251: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14251
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: coreutils-8.15: tail.c : Need support for StorNext file system as distributed file system Date: Wed, 24 Apr 2013 06:47:19 +0000

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.

--- End Message ---
--- Begin Message --- 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 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2
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.

Attachment: snfs.patch
Description: Text Data


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]