Bug 155624 - NFS mounted IRIX64 filesystems do not display all files
NFS mounted IRIX64 filesystems do not display all files
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Steve Dickson
Brian Brock
http://www.ussg.iu.edu/hypermail/linu...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-21 18:16 EDT by Kristofer Modig
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version: 2.6.15-1.1831_FC4smp
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-05-05 17:19:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kristofer Modig 2005-04-21 18:16:53 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)

Description of problem:
When mounting an IRIX (version  6.5.11m, 64-bit) filesystem with kernel-2.6 (any version used in FC3) not all files are displayed on that file system in certain programs, for example with the Open File dialog in Acrobat reader 5. Since my home directory is on the mounted system, this gives a lot of trouble for me: gnome preferences are not read properly, Mozilla/Firefox plugins are not found, matlab files are not found by matlab, etc, etc. This seem to be the old "readdir" bug, addressed in kernel 2.4 by Red Hat (see URL above). I also guess this is related to bug 141167, where later versions of find-utils fail on IRIX file systems.
The problem seems to have been addressed before by Red Hat. See for example http://www.ussg.iu.edu/hypermail/linux/kernel/0406.2/0173.html.

Version-Release number of selected component (if applicable):
kernel-2.6.11-1.14_FC3

How reproducible:
Always

Steps to Reproduce:
1.Export a irix64 xfs (version 1) filesystem, with -32bitclients option.
2.Mount the file system on Fedora Core 3
3.Some files will not be shown in acroread 5 open file dialog, not found by matlab (although on search path), etc. find does not work. ls normally shows all files, as it seems.
  

Additional info:
Comment 1 Jonas Maebe 2005-06-09 10:49:38 EDT
I have a similar problem with an NFS mount exported from a Mac OS X 10.4.1 machine and mounted on 
either Fedora Core 2 or 3 (x86) machines. I'm experiencing e.g. the cvs problem mentioned in https://
bugzilla.redhat.com/bugzilla/show_bug.cgi?id=55864:

cvs update: error reading current directory: Value too large for defined data type

The supplied test program from that bugreport also only reports "." and ".." for every directory mounted 
via NFS from the Mac OS X 10.4.1 machine.
Comment 2 Jonas Maebe 2005-06-09 14:09:33 EDT
See also http://www.omnigroup.com/mailman/archive/macosx-admin/2005-June/042661.html for a 
comment from an Apple engineer.

And sorry for the botched url in the previous comment, here it is in one piece (I hope):  https://
bugzilla.redhat.com/bugzilla/show_bug.cgi?id=55864
Comment 3 Dave Jones 2005-07-15 15:56:27 EDT
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem.   Please update to this new kernel, and
report whether or not it fixes your problem.

If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.

Thank you.
Comment 4 Kristofer Modig 2005-08-15 03:50:11 EDT
kernel-2.6.12-1.1372_FC3 did not fix the problem for me. Why not just reapply
the old solution Red Hat had before? I got a patch (based on the 2.4 patch, I
think. Thanks to Peter Wainwright!) to kernel 2.6.10 and compiled it into 2.6.11
myself and it now works fine.
Comment 5 Steve Dickson 2005-08-15 13:46:33 EDT
It does appear that FC4 does have the patch in question. Please
give a try and let us know if there is still problem...
Comment 6 Jonas Maebe 2005-08-24 07:08:49 EDT
I just wanted to note that kernel-2.6.12-1.1372_FC3 did not solve the problem for me either. I do not 
have access yet to a FC4 machine to test (some machines here are even still at FC2).
Comment 7 Greg Ercolano 2005-11-20 03:20:08 EST
I noticed these things about this problem:

    o 'find /mount/path' will show the 'Value too large..' error.
      Similarly, invoking find(1) on any valid path to the SGI nfs server
      will give this error. Passing a path that doesn't exist gives the usual
      ENOENT.

    o A small test program using opendir()/readir() to open the mount point
      returns no files, and no errors. However, passing a valid path to levels
      below the mount point will sometimes yield results, sometimes nothing.

    o Compiling the example from the scandir(3) man page shows the same
      results as find(1); any existing directory will fail (even those that
      show a proper report with opendir/readdir)

    o When Firefox is given the /mount/path as a url, it behaves the same
      as the opendir/readdir program; for some dirs, no output, for others,
      a complete directory listing.

    o 'ls /mount/path' and gnome's file browser both work fine (shows all
       files all the time) I looked at the code for ls(1), but couldn't
       determine what's different about it; it uses opendir()/readdir() too,
       it seems. Hard to tell with all those #ifdef's.
Comment 8 Greg Ercolano 2005-11-20 03:51:36 EST
Followup: regarding compiling simple opendir()/readdir() and scandir() programs,
I see the problem: these simple programs will work *fine* with the SGI mount
*if* you compile the program as:

    gcc -D_FILE_OFFSET_BITS=64 opendir.c -o opendir
    gcc -D_FILE_OFFSET_BITS=64 scandir.c -o scandir
        ^^^^^^^^^^^^^^^^^^^^^^

..without that flag, the binaries behave as described (in Comment#7).
..with the flag, the binaries behave normally..!

My understanding is this flag enables 64 bit functions, data structures, and
data types to use the wider data types (eg. off_t might be a ulong instead of a
uint), even though you're on a 32 bit local system. More info here:
http://www.suse.de/~aj/linux_lfs.html
..scroll down to the "Using LFS" section for the GCC flag info.

So if you're a code developer, you can probably 'fix' your programs by just
recompiling with that flag enabled.

It sounds like the problem with find(1) and Firefox *might* be they weren't
compiled with this flag enabled; if they were, they might work normally. In my
case, this was an FC3 system mounting the SGI.

So instead of trying to apply kernel patches, try recompiling your binaries,
ensuring the above flag is enabled.
Comment 9 Dave Jones 2006-01-16 17:31:38 EST
This is a mass-update to all currently open Fedora Core 3 kernel bugs.

Fedora Core 3 support has transitioned to the Fedora Legacy project.
Due to the limited resources of this project, typically only
updates for new security issues are released.

As this bug isn't security related, it has been migrated to a
Fedora Core 4 bug.  Please upgrade to this newer release, and
test if this bug is still present there.

This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

Thank you.
Comment 10 Dave Jones 2006-02-03 01:49:13 EST
This is a mass-update to all currently open kernel bugs.

A new kernel update has been released (Version: 2.6.15-1.1830_FC4)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

Thank you.
Comment 11 Jonas Maebe 2006-04-20 03:52:39 EDT
I can confirm the bug is fixed at least in Kernel 2.6.15-1.1831_FC4smp
Comment 12 John Thacker 2006-05-05 17:19:15 EDT
Closing per previous comments.

Note You need to log in before you can comment on or make changes to this bug.