GNU bug report logs -
#14251
coreutils-8.15: tail.c : Need support for StorNext file system as distributed file system
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 14251 in the body.
You can then email your comments to 14251 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org
:
bug#14251
; Package
coreutils
.
(Wed, 24 Apr 2013 07:10:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Guenter Ressel-Herbert <Guenter.Ressel-Herbert <at> quantum.com>
:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org
.
(Wed, 24 Apr 2013 07:10:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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.
[Message part 2 (text/html, inline)]
Reply sent
to
Pádraig Brady <P <at> draigBrady.com>
:
You have taken responsibility.
(Wed, 24 Apr 2013 22:14:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Guenter Ressel-Herbert <Guenter.Ressel-Herbert <at> quantum.com>
:
bug acknowledged by developer.
(Wed, 24 Apr 2013 22:14:02 GMT)
Full text and
rfc822 format available.
Message #10 received at 14251-done <at> debbugs.gnu.org (full text, mbox):
[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)]
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#14251
; Package
coreutils
.
(Thu, 25 Apr 2013 04:10:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 14251 <at> debbugs.gnu.org (full text, mbox):
Pádraig Brady wrote:
> 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
Looks fine. Thanks.`
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#14251
; Package
coreutils
.
(Thu, 25 Apr 2013 07:21:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 14251-done <at> debbugs.gnu.org (full text, mbox):
> On April 25, 2013 at 12:08 AM Pádraig Brady <P <at> draigBrady.com> wrote:
> 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.
Hi Padraig,
I also searched a bit for 0xBEEFDEAD, but I couldn't find
a good document related to StorNext. Where did you find
the file system name? Should we add such an URL to the commit?
Otherwise, the patch looks good.
Have a nice day,
Berny
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#14251
; Package
coreutils
.
(Thu, 25 Apr 2013 08:59:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 14251 <at> debbugs.gnu.org (full text, mbox):
On 04/25/2013 08:15 AM, Bernhard Voelker wrote:
>> On April 25, 2013 at 12:08 AM Pádraig Brady <P <at> draigBrady.com> wrote:
>> 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.
>
> Hi Padraig,
>
> I also searched a bit for 0xBEEFDEAD, but I couldn't find
> a good document related to StorNext. Where did you find
> the file system name? Should we add such an URL to the commit?
I got the name from just searching for snfs and cvfs.
There were various URLs referring to both.
As for BEEFDEAD, I didn't see anything online.
Guenter, can you post a link to the GPL client code
so we can link/verify?
> Otherwise, the patch looks good.
thanks,
Pádraig.
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#14251
; Package
coreutils
.
(Thu, 25 Apr 2013 16:12:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 14251 <at> debbugs.gnu.org (full text, mbox):
On 04/25/2013 09:53 AM, Pádraig Brady wrote:
> On 04/25/2013 08:15 AM, Bernhard Voelker wrote:
>>> On April 25, 2013 at 12:08 AM Pádraig Brady <P <at> draigBrady.com> wrote:
>>> 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.
>>
>> Hi Padraig,
>>
>> I also searched a bit for 0xBEEFDEAD, but I couldn't find
>> a good document related to StorNext. Where did you find
>> the file system name? Should we add such an URL to the commit?
>
> I got the name from just searching for snfs and cvfs.
> There were various URLs referring to both.
>
> As for BEEFDEAD, I didn't see anything online.
> Guenter, can you post a link to the GPL client code
> so we can link/verify?
Sorry I got confused with FhGFS, which has GPL clients.
thanks,
Pádraig.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 24 May 2013 11:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 10 years and 356 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.