Bug 211070

Created attachment 138655 [details]
strace 2.6.17-1.2187_FC5

Created attachment 138656 [details]
strace 2.6.18-1.2200.fc5

I added two attachements. One from each kernel version running an strace ls on
the same directory in the cifs mounted share. strace 2.6.17-1.2187_FC5 shows a
successful ls and strace 2.6.18-1.2200.fc5 shows the unsuccessful ls.

same here. when a shared folders have more then a few hundred folders or files
inside, this one can not be read.

ls: reading directory /mnt/share/: Invalid argument

the same problem has fc6 (rawhide) since the last (about)10-20 kernels.

I have the same issue when connecting a FC5 box with kernel 2.6.18-1.2200 to a
FC5 server. I can mount the share but listing the dir results in 'Invalid argument'.

I was able to update to the same kernel and reproduce the problem.

filldir is returning rc=22, partway through a directory listing (on entry 113
out   of 317).  cifs is not expecting filldir to fail with this error and it
works with other kernels and similar versions of the cifs readdir code.

It may be an SELinux interaction.

I have SELinux disabled on my box so I don't think SELinux is the problem.

Same here, SELinux disabled on FC5 and Rawhide, the problem exists further.

Ditto....SELinux is also disabled on the workstation that we have this issue 
with.

I am looking at this section of fs/readdir.c for the likely source of the -22 error:

static int filldir64(void * __buf, const char * name, int namlen, loff_t offset,
                    u64 ino, unsigned int d_type)
{
        struct linux_dirent64 __user *dirent;
        struct getdents_callback64 * buf = (struct getdents_callback64 *) __buf;
        int reclen = ROUND_UP64(NAME_OFFSET(dirent) + namlen + 1);

        buf->error = -EINVAL;   /* only used if we fail.. */
        if (reclen > buf->count)
                return -EINVAL;

Am downloading, modifying with some trace code, and rebuilding the matching
kernel source for this fc5 kernel now

in fs/readdir.c in filldir64 (2.6.18-FC5)

the vfs is checking
    if (reclean > buf->count)
          return -EINVAL


In this case, reclen is 40 and count is zero  (this is called from ls going to
vfs_readdir to cifs_readdir to cifs_filldir which is calling filldir, which is
failing

Created attachment 138936 [details]
proposed fix

This is probably a dupe of Bug 206103

Yes that bug is a duplicate but I don't seem to have authority to dup it to this.

The fix is fairly obvious, the only thing bothering me is figuring out what changed

(since this did not use to fail, and doesn't fail on mainline kernel at the same
kernel level to the same directory in my tests, and this section of cifs_readdir
did not change I am curious)

*** Bug 211582 has been marked as a duplicate of this bug. ***

*** Bug 206103 has been marked as a duplicate of this bug. ***

(In reply to comment #15)
> Yes that bug is a duplicate but I don't seem to have authority to dup it to this.

I did -- we just need to remember that this bug needs to be fixed in devel, fc6
and fc5!

I've merged this to all Fedora branches, and will get updates out soon.

As for why this broke in Fedora but not mainline.. We do have some cachefs
patches, and some funky 64bit inode patches (though I believe all of these are
in -mm, so that may be similarly affected).  CC'ing the usual suspects who may
have additional clues.

Thanks for getting this fixed. Will be looking forward to the updates. Will this
be included in the iso files when FC6 is released?

No, the FC6 ISOs already got created and started pushing out to the mirror
servers, so it's too late.   It'll get into the first update thats available for
it though, which shouldn't be too far away.

I was curious too about why this doesn't seem to fail upstream (not that I've
tested it upstream, but I'll take Steve's word for it..!)

In my setup, some directories will return many entries before an EINVAL.

For example one directory comes up with num_to_fill == 128 in cifs_readdir(),
and successfully fills those.  Then it comes back for another 128 and on
the last couple iterations of the loop:

loop: i == 126
calling filldir with i_ino 8416 name seq len 3 f_pos 384
reclen 24 buf->count 32
namlen 3 NAME_OFFSET(dirent) 19
cifs_filldir got 0

loop: i == 127
calling filldir with i_ino 8417 name kfile len 5 f_pos 385
reclen 32 buf->count 8
namlen 5 NAME_OFFSET(dirent) 19
reclen > buf->count
filldir rc = -22
cifs_filldir got -22

So, is this possibly a miscalculation of num_to_fill, and an unexpected error?

Otherwise it looks like a normal "we ran out of room so return" sort of error,
but then why wouldn't it behave the same upstream?

So, this seems to be related to
"linux-2.6-inode-diet-eliminate-i_blksize-and-use-a-per-superblock-default.patch"
if I did my patch bisection right :)

The patch doesn't much touch cifs, it just removes this line:

-       cifs_inode->vfs_inode.i_blksize = CIFS_MAX_MSGSIZE;

since i_blksize doesn't exist anymore.  I'm not sure at first glance why this
would change cifs' behavior...?

Ohhhh ok, one more tidbit, 2.6.19-rc2's generic_fillattr does:

+       stat->blksize = (1 << inode->i_blkbits);

while fc6 does:

+       stat->blksize = PAGE_CACHE_SIZE;

so fc6 is doing getdents to cifs in 4k chunks instead of 16k.

cifs should probably still cope, though.  But anyway, 99% sure that's the change
that matters.  I'll give it a test when I have a bit more time.

confirmed, that change to generic_filldir makes things work as before.

*** Bug 211832 has been marked as a duplicate of this bug. ***

This looks to be the same issue?
http://lists.samba.org/archive/linux-cifs-client/2006-September/001483.html

Brian, yep, same issue.  Guess I re-discovered a known issue.  :)

This is only repot:
In 2.6.18-1.2798.fc6 kernel is this problem too.
Shared directory which contain more then 100 files (I am sorry, i don't know
exactly number) show no files and looks like empty.

Adding my symptom as others seem to get slightly different manifestation.
Using CIFS from FC5 to access and backup win server 03 user files, after update
to 2.6.18 was missing about 1/3 files which turned out to various directories
completely skipped. Researched a few and found the access to folders failed if
the folder 'file' size was > 56MB. 56MB as reported by windows if there were no
subdirectories. Using different files allowed different number of files - but
not more than 56MB. If there were subdirectories then the windows reported size
could be bigger but the top directory was still limited. If I added a
subdirectory then I needed to remove a file from folder - I am assuming here
that a directory entry had a similar effect to a small file, but the size of
files in that directory had no affect. 
I am using 32bit intel system - methinks platform tag for this bug needs to be
relaxed.

I see the same bug as the original Bug report (ls: reading directory .: Invalid
argument".) on two FC5 ia32 Systems. With kernel Version 2.17 everything worked
fine.

Just to summarize - 
readdir (ls) will fail on cifs with 2.6.18-fc6, and similar fc5 versions for
directories which contain about 120 files or more (it depends on the length of
the file names)

As Eric found (see above) the bug shows up because the Fedora kernel now sets
the recommended i/o size on cifs inodes incorrectly (it was set based on blkbits
which for cifs is 16K - but that was removed and it now is incorrectly set to
the smaller value of page size).  This causes filldir to run out of space, and
cifs was incorrectly returning errors on filldir - causing readdir to fail, when
it was simply temporarily out of space in the buffer.

There is a patch (see above) attached for cifs (to not pass back the return code
on filldir) which addresses the problem which has been reported.   Ideally there
should be a second change, as Shaggy and Eric noted, ie cifs_getattr also should
override the incorrect value of stat->blksize, but this is tricky because
presumably that patch is not needed in mainline (which still uses the value of
blkbits to set blksize).   Without that second change, fc will be significantly
slower on sequential operations on fast networks for certain cases (e.g. cifs
mount with forcedirectio option, and somewhat slower on readdir).   I don't know
whether it is worth making the 2nd change to cifs (to set the blocksize) until
we determine whether fc5 is going to keep the

"linux-2.6-inode-diet-eliminate-i_blksize-and-use-a-per-superblock-default.patch"

In any case - if problems with readdir on either of these fc releases - the
attached patch should address them (which if I read the comments above correctly
apparently will be included in the next fc update).

Steve, thanks for the summary.

It seems to me that we should do all 3 things:

a) update the inode diet patch to set the default VFS IO size to use blkbits in
FC, as it is upstream
b) fix cifs readdir to cope with smaller buffers just in case, since the IO size
is only a "hint" not a requirement, and
c) change cifs_getattr to set the optimal cifs IO size hint to CIFS_MAX_MSGSIZE
regardless of the VFS default, in case the VFS changes again...

sound reasonable?  My change noted in comment #26 does a), Steve - your original
attached patch does b), and c) could be changed at any later point, since w/ a)
and b) cifs should be in good shape for now.

-Eric

*** Bug 213308 has been marked as a duplicate of this bug. ***

Any idea when this fix is going to be available as an update? This is a show
stopper from moving to FC6, which I would like to do.

Or if somebody could point me in the direction to recompiling the kernel as I
looked in to /usr/src/kernels/2.6.18-1.2200.fc5-x86_64/fs/cifs and the readdir.c
file is not there.

Sorry if this is a newbie question however I haven't recompiled a kernel before.

seems to be fixed in latest kernel in updates-testing for FC5 & 6

great work, thx!

should be fixed in 2.6.18-1.2239.fc5 now in updates.

2239 seems to have fixed it on my system.

Hi guys,

I am running into the same issue with 2.6.18-1.2798.fc6

Do I need to apply a patch or am I the only one?

Thanks,

Jorge

2.6.18-1.2869.fc6 is the actual kernel and the issue is fixed since 2.6.18-1.2239.

Hmm yep should be fixed.  Can you strace the failing command, for a start?

I had Fedora Core 4 and this was all working fine.

Basically I have a dev server with mounted Windows partitions:
mount -t cifs //10.1.1.4/Videos /mnt/mediavideos -o
username=Administrator,password=******,rw,domain=expotv

Then I do:
cd /mnt/mediavideos

And then "ls", I get the proper directory:
[root@dev mediavideos]# ls
Downloads  logs  Raw Files on Stor1.lnk  Transcoding

I did an strace of this command, though, and I get these messages:
execve("/bin/ls", ["ls"], [/* 23 vars */]) = 0
chdir(0x8)                              = 6377472
link(0x1000, 0xffffffff)                = -1431654400
dup2(-453835200, -1)                    = 0
mount(NULL, 0xffffffff, 0xe761ad20, MS_NODEV, 0xe74179a0) = -1 ENOENT (No such
file or directory)
fork()                                  = 3
open(0xffffffff, 0, 034474576460)       = 0
link(0xffffffff, 0xffffffff)            = -1431650304
read(-1431650304, 0xffffffff, 1)        = 0
fork()                                  = 3
restart_syscall(<... resuming interrupted call ...>) = 832
open(0xaaaab000, 0, 034474576560)       = 0
link(0x1000, 0xffffffff)                = -1431572480
link(0xe4f30118, 0xffffffff)            = -390070272
unlink(0xe4f2fb10)                      = 0
link(0xe4f2fb40, 0xffffffff)            = -387944448
read(1879047935, 0xffffffff, 3907026696) = 0
fork()                                  = 3
restart_syscall(<... resuming interrupted call ...>) = 832
open(0xaaaab000, 0, 034474576500)       = 0
link(0xe4f30008, 0xffffffff)            = -394264576
unlink(0xe4f2fba0)                      = 0
link(0xe4f2fbd0, 0xffffffff)            = -392146944
read(1879047935, 0xffffffff, 0)         = 0
fork()                                  = 3
restart_syscall(<... resuming interrupted call ...>) = 832
open(0xaaaab000, 0, 034474576420)       = 0
link(0xe4f30048, 0xffffffff)            = -381681664
unlink(0xe4f2fb10)                      = 0
link(0xe4f2fb40, 0xffffffff)            = -379502592
link(0xe4f2fb40, 0xffffffff)            = -379494400
read(1879047935, 0xffffffff, 0)         = 0
fork()                                  = 3
restart_syscall(<... resuming interrupted call ...>) = 832
open(0xaaaab000, 0, 034474576340)       = 0
link(0x1000, 0xffffffff)                = -1431568384
link(0xe4f300c0, 0xffffffff)            = -411041792
unlink(0xe4f2fa50)                      = 0
link(0xe4f2fa80, 0xffffffff)            = -407617536
link(0xe4f2fa80, 0xffffffff)            = -407597056
read(1879047935, 0xffffffff, 3887365296) = 0
fork()                                  = 3
restart_syscall(<... resuming interrupted call ...>) = 832
open(0xaaabf000, 0, 034474575640)       = 0
link(0xe4f2ff48, 0xffffffff)            = -398458880
unlink(0xe4f2f940)                      = 0
link(0xe4f2f970, 0xffffffff)            = -396279808
link(0xe4f2f970, 0xffffffff)            = -396271616
read(1879047935, 0xffffffff, 3898691320) = 0
fork()                                  = 3
restart_syscall(<... resuming interrupted call ...>) = 832
open(0xaaabf4b8, 0, 034474575120)       = 0
link(0xe4f2fd18, 0xffffffff)            = -356515840
unlink(0xe4f2f8b0)                      = 0
link(0xe4f2f8e0, 0xffffffff)            = -354406400
read(1879047935, 0xffffffff, 0)         = 0
fork()                                  = 3
restart_syscall(<... resuming interrupted call ...>) = 832
open(0xaaabf970, 0, 034474574460)       = 0
link(0x1000, 0xffffffff)                = -1431564288
link(0xe4f2fcd8, 0xffffffff)            = -406847488
unlink(0xe4f2f6d0)                      = 0
link(0xe4f2f700, 0xffffffff)            = -404742144
read(1879047935, 0xffffffff, 0)         = 0
fork()                                  = 3
restart_syscall(<... resuming interrupted call ...>) = 832
open(0xaaabf970, 0, 034474574400)       = 0
link(0xe4f2fbc8, 0xffffffff)            = -377487360
unlink(0xe4f2f760)                      = 0
link(0xe4f2f790, 0xffffffff)            = -375148544
link(0xe4f2f790, 0xffffffff)            = -375144448
read(1879047935, 0xffffffff, 0)         = 0
link(0x1000, 0xffffffff)                = -1431560192
link(0x1000, 0xffffffff)                = -1431556096
sched_yield()                           = 0
unlink(0xaaabf000)                      = 0
unlink(0xaaabfe28)                      = 0
unlink(0xaaac02e0)                      = 0
unlink(0xe761a5e8)                      = 0
unlink(0xaaac0cd0)                      = 0
execve(NULL, [0xffffffff], [/* 0 vars */]) = 0
mincore(0xaaac02e0, 4294967295, 0xe4f30988) = 2560
vserver(0xaaac02e0, 0xffffffff, 0xe4f30988, 0x18, 0xaaac2c70) = 0
time(0xe4f30690)                        = 0
time(0xe4f30690)                        = 0
mknod(0xaaac02e0, 037777777777)         = 0
setpriority(0xaaac02e0 /* PRIO_??? */, 4294967295, 15) = 0
mount(0xe9614d98, 0xffffffff, 0xe4f30988, 0, 0xe9412648) = 0
chdir(0xe7b4a9f0)                       = 6377472
chdir(0x615000)                         = 6512640
fork()                                  = 3
open("ˆ¤­û", 0, 034474603440)           = 0
link(0x1000, 0xffffffff)                = -1431650304
restart_syscall(<... resuming interrupted call ...>) = 511
restart_syscall(<... resuming interrupted call ...>) = 0
read(6377488, 0xffffffff, 4222460952)   = 0
execve(".¤­û", [0xffffffff], [/* 0 vars */]) = 0
fork()                                  = 3
open("ˆ$­û", 0, 034474603400)           = 0
link(0x1000, 0xffffffff)                = -1431650304
restart_syscall(<... resuming interrupted call ...>) = 968
restart_syscall(<... resuming interrupted call ...>) = 0
read(6378704, 0xffffffff, 4222428184)   = 0
execve(".$­û", [0xffffffff], [/* 0 vars */]) = 0
fork()                                  = 3
open(0xe4f30410, 0, 034755107700)       = 0
link(0x34f2da0, 0xffffffff)             = -1431552000
read(55520672, 0xffffffff, 80884)       = 0
lchown(0xe7619bc0, -1, 3841132256)      = 0
lchown(NULL, -1, 3841132624)            = 0
fork()                                  = 3
open(0x3, 0, 034474601460)              = 0
sigsuspend([HUP])                       = 0
gettimeofday({3, 0}, {...})             = 184
gettimeofday({3, 0}, {...})             = 0
read(0, 0xffffffff, 3887372768)         = 0
open(0xe7b48780, 0, 034474533200)       = 0
link(0x1000, 0xffffffff)                = -1376030720
_exit(53)                               = ?

But I get the directory anyway.

If I now change to:
[root@dev mediavideos]# cd Transcoding/AOL\ 3\ Formats/Output/

and do ls:
[root@dev Output]# ls
ls: reading directory .: Invalid argument

This is the strace for this one:
execve("/bin/ls", ["ls"], [/* 23 vars */]) = 0
chdir(0x8)                              = 6377472
link(0x1000, 0xffffffff)                = -1431654400
dup2(-609889984, -1)                    = 0
mount(NULL, 0xffffffff, 0xe761ad20, MS_NODEV, 0xe74179a0) = -1 ENOENT (No such
file or directory)
fork()                                  = 3
open(0xffffffff, 0, 033351344060)       = 0
link(0xffffffff, 0xffffffff)            = -1431650304
read(-1431650304, 0xffffffff, 1)        = 0
fork()                                  = 3
restart_syscall(<... resuming interrupted call ...>) = 832
open(0xaaaab000, 0, 033351344160)       = 0
link(0x1000, 0xffffffff)                = -1431572480
link(0xdba5cc18, 0xffffffff)            = -390070272
unlink(0xdba5c610)                      = 0
link(0xdba5c640, 0xffffffff)            = -387944448
read(1879047935, 0xffffffff, 3907026696) = 0
fork()                                  = 3
restart_syscall(<... resuming interrupted call ...>) = 832
open(0xaaaab000, 0, 033351344100)       = 0
link(0xdba5cb08, 0xffffffff)            = -394264576
unlink(0xdba5c6a0)                      = 0
link(0xdba5c6d0, 0xffffffff)            = -392146944
read(1879047935, 0xffffffff, 0)         = 0
fork()                                  = 3
restart_syscall(<... resuming interrupted call ...>) = 832
open(0xaaaab000, 0, 033351344020)       = 0
link(0xdba5cb48, 0xffffffff)            = -381681664
unlink(0xdba5c610)                      = 0
link(0xdba5c640, 0xffffffff)            = -379502592
link(0xdba5c640, 0xffffffff)            = -379494400
read(1879047935, 0xffffffff, 0)         = 0
fork()                                  = 3
restart_syscall(<... resuming interrupted call ...>) = 832
open(0xaaaab000, 0, 033351343740)       = 0
link(0x1000, 0xffffffff)                = -1431568384
link(0xdba5cbc0, 0xffffffff)            = -411041792
unlink(0xdba5c550)                      = 0
link(0xdba5c580, 0xffffffff)            = -407617536
link(0xdba5c580, 0xffffffff)            = -407597056
read(1879047935, 0xffffffff, 3887365296) = 0
fork()                                  = 3
restart_syscall(<... resuming interrupted call ...>) = 832
open(0xaaabf000, 0, 033351343240)       = 0
link(0xdba5ca48, 0xffffffff)            = -398458880
unlink(0xdba5c440)                      = 0
link(0xdba5c470, 0xffffffff)            = -396279808
link(0xdba5c470, 0xffffffff)            = -396271616
read(1879047935, 0xffffffff, 3898691320) = 0
fork()                                  = 3
restart_syscall(<... resuming interrupted call ...>) = 832
open(0xaaabf4b8, 0, 033351342520)       = 0
link(0xdba5c818, 0xffffffff)            = -356515840
unlink(0xdba5c3b0)                      = 0
link(0xdba5c3e0, 0xffffffff)            = -354406400
read(1879047935, 0xffffffff, 0)         = 0
fork()                                  = 3
restart_syscall(<... resuming interrupted call ...>) = 832
open(0xaaabf970, 0, 033351342060)       = 0
link(0x1000, 0xffffffff)                = -1431564288
link(0xdba5c7d8, 0xffffffff)            = -406847488
unlink(0xdba5c1d0)                      = 0
link(0xdba5c200, 0xffffffff)            = -404742144
read(1879047935, 0xffffffff, 0)         = 0
fork()                                  = 3
restart_syscall(<... resuming interrupted call ...>) = 832
open(0xaaabf970, 0, 033351342000)       = 0
link(0xdba5c6c8, 0xffffffff)            = -377487360
unlink(0xdba5c260)                      = 0
link(0xdba5c290, 0xffffffff)            = -375148544
link(0xdba5c290, 0xffffffff)            = -375144448
read(1879047935, 0xffffffff, 0)         = 0
link(0x1000, 0xffffffff)                = -1431560192
link(0x1000, 0xffffffff)                = -1431556096
sched_yield()                           = 0
unlink(0xaaabf000)                      = 0
unlink(0xaaabfe28)                      = 0
unlink(0xaaac02e0)                      = 0
unlink(0xe761a5e8)                      = 0
unlink(0xaaac0cd0)                      = 0
execve(NULL, [0xffffffff], [/* 0 vars */]) = 0
mincore(0xaaac02e0, 4294967295, 0xdba5d488) = 2525
vserver(0xaaac02e0, 0xffffffff, 0xdba5d488, 0x18, 0xaaac2c70) = 0
time(0xdba5d190)                        = 0
time(0xdba5d190)                        = 0
mknod(0xaaac02e0, 037777777777)         = 0
setpriority(0xaaac02e0 /* PRIO_??? */, 4294967295, 15) = 0
mount(0xe9614d98, 0xffffffff, 0xdba5d488, 0, 0xe9412648) = 0
chdir(0xe7b4a9f0)                       = 6377472
chdir(0x615000)                         = 6512640
fork()                                  = 3
open("ˆ¤­û", 0, 033351351040)           = 0
link(0x1000, 0xffffffff)                = -1431650304
restart_syscall(<... resuming interrupted call ...>) = 511
restart_syscall(<... resuming interrupted call ...>) = 0
read(6377488, 0xffffffff, 4222460952)   = 0
execve(".¤­û", [0xffffffff], [/* 0 vars */]) = 0
fork()                                  = 3
open("ˆ$­û", 0, 033351351000)           = 0
link(0x1000, 0xffffffff)                = -1431650304
restart_syscall(<... resuming interrupted call ...>) = 968
restart_syscall(<... resuming interrupted call ...>) = 0
read(6378704, 0xffffffff, 4222428184)   = 0
execve(".$­û", [0xffffffff], [/* 0 vars */]) = 0
fork()                                  = 3
open(0xdba5cf10, 0, 034755107700)       = 0
link(0x34f2da0, 0xffffffff)             = -1431552000
read(55520672, 0xffffffff, 80884)       = 0
lchown(0xe7619bc0, -1, 3685077472)      = 0
lchown(NULL, -1, 3685077840)            = 0
fork()                                  = 3
open(0x3, 0, 033351347060)              = 0
sigsuspend([HUP])                       = 0
gettimeofday(0x61b070, 0xffffffff)      = -1 EINVAL (Invalid argument)
fork()                                  = 4
open("ˆ¤­û", 0, 033351344360)           = 0
link(0x1000, 0xffffffff)                = -1376030720
restart_syscall(<... resuming interrupted call ...>) = 2528
restart_syscall(<... resuming interrupted call ...>) = 0
read(6406320, 0xffffffff, 4222460952)   = 0
execve(".¤­û", [0xffffffff], [/* 0 vars */]) = 0
fork()                                  = -1 ENOENT (No such file or directory)
fork()                                  = -1 ENOENT (No such file or directory)
fork()                                  = -1 ENOENT (No such file or directory)
fork()                                  = -1 ENOENT (No such file or directory)
fork()                                  = -1 ENOENT (No such file or directory)
fork()                                  = -1 ENOENT (No such file or directory)
_exit(4)                                = ?

Ok, that's a bit odd, the only EINVAL I see is from gettimeofday... and the args
to it look a bit suspicious.

Can you try again with the -f argument to strace, lots of forks in there. 
Please add it as an attachment, thanks.

-Eric

Created attachment 145702 [details]
strace with -F option

Hi Eric,

Thanks for your help. Here's the strace.

Jorge

Hi, need -f not -F please.

Thanks,
-Eric

Created attachment 145713 [details]
New strace with -f option

Sorry, here goes.

Unfortunately that's even less info, I'm not sure why.  And your ls strace
output doesn't look anything like what I see when I strace LS on fc6, at least.

I need some indication of -what- is failing when you run ls... I may have to do
some testing myself here when I get some time.

Is anyone else on this bug seeing the problem on recent kernels?

Created attachment 145717 [details]
Directory contents snapshot

This is the listing of files in that directory. Basically, when I had Fedora
Core 4 in that server, I can do ls and, most importantly, fetch the directory
contents from some PHP scripts I have running in there.

Now when I navigate to that folder and type ls I get:
[root@dev AOL 3 Formats]# ls
ls: reading directory .: Invalid argument

This may or may not help but just in case your problem is related to Bug 211672.
While the remote share is mounted, what do you get by this command?

cat /proc/fs/cifs/DebugData

Do you see any garbled characters?

Akemi

Created attachment 145726 [details]
Cat dump

Hi Akemi,

I do see a lot of garbled characters...

I saw something about a patch for cifs on that bug you sent, but didn't quite
get why these are related.

Can you point me in the right direction?

Thanks!

I do not know if the problem you are having is related to that bug.  I only
wondered what if...

However, there is a way to find out the answer.  That is to apply the patch to
your cifs and see if your problem goes away.  In any case, cifs 1.45 and newer
has this bug and it is indeed a good idea for anyone to be running the patched
version.

Akemi

Hi Akemi,

Can you email me how exactly to apply this patch?

I'm experienced but not too much on patches... :)

Thanks!

getting "invalid argument" on ls over cifs mounts, and only getting it after
putting on fc5 is almost certainly the same problem as was fixed by this bugfix.

Doesn't FC5 service update include this fix?   Certainly more recent kernels
have the fix.

Ok, Jorge, reading back through the comments, I'm confused about which kernel
you are actually running here.

Can you be sure you are actually running the latest kernel (uname -r to check)
from FC updates, and give it another try please.  This should have been fixed
long ago.

Now I see.  Jorge is running 2.6.18-1.2798.fc6 (comment #43) which is the
original FC6 kernel (without this bugfix).

Right --
[root@dev corey]# uname -r
2.6.18-1.2798.fc6

Right, so Jorge, please get the latest kernel from updates.

Sorry, I should have caught that a -long- time ago, misread the kernel he was
running.

Hi guys,

I finally solved the problem -- the issue was that I had Fedora Core 5 with the
32 bit install, and we upgraded to the 64 bit version of Fedora Core 6, which
created a myriad of issues with different versions of libraries, etc. etc.

I did a clean install of Fedora Core 6, 32 bit, and the server is finally
running very well and so far no issues with the SATA drives freezing or the 128+
ls bug.

Thanks so much for the help, very specially to Akemi and Eric!

Keep on Fedorin'

I have the same issue on 2.6.18-1.2798.fc6, anybody can help?

tnx

Unfortunately, Fedora Core 6 is no longer maintained.  Could you attempt to
reproduce this on Fedora 8? 

On my FC5 box I just use the smfs kernel module and built the smbmount,
smbumount, and smbmnt binaries. You can follow the directions on this site.

http://www-user.tu-chemnitz.de/~tott/FC5-smbfs-HOWTO.html

Then just mount them as smfs shares vs cifs. This should work for FC6 with
slight modifications of the source rpms to download.

(In reply to comment #64)
> Unfortunately, Fedora Core 6 is no longer maintained.  Could you attempt to
> reproduce this on Fedora 8? 

We installed FC8, kernel 2.6.23.

On this version CIFS share works fine, thanks!