Chris Mason wrote:
> On Tue, 2009-01-13 at 13:38 -0700, Matthew Wilcox wrote:
>   
>> On Tue, Jan 13, 2009 at 11:37:00AM -0800, Andrew Morton wrote:
>>     
>>> I'd have expected to see stat() returning -EOVERFLOW, but it isn't there.
>>>
>>> googling around a bit seems to indcate that this might be a glibc issue:
>>>
>>> http://sourceware.org/bugzilla/show_bug.cgi?id=1864
>>> http://bugs.gentoo.org/show_bug.cgi?id=146951
>>>
>>> But the traces are all using stat64() and fstat64().  And why would it
>>> just start occurring now?
>>>       
>> Maybe glibc is using the 64-bit stat calls and returning -EOVERFLOW to
>> the application when the results from the kernel turn out to be > 32-bit
>> in size?
>>
>>     
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6c31b93a14a453c8756ffd228e24910ffdf30c5d
>
> I'd guess the commit above is related, although I don't see any way for
> it to make things interesting without the user doing mount -o inode64.
>
> strace -v should show us more, it would show if the inode numbers coming
> out of stat64 are big.
>
> -chris
>
>   
I cannot fully understand what strace -v outputs (see attachment), but 
what i see is that 'find' stops after finding a file with d_off = 4294967295
4294967295  =  0xFFFFFFFF, adding any number greater that zero will be 
greater that 32bits, so this could be the reason for the message "value 
too large".



I also noticed that i cannot access these files through samba if i boot 
from 2.6.28 - really strange.
If i reboot older kernels these are visible in samba again and fully 
accessible.

Attached the log from stracing the command which was ivoked by the 
Makefile from v4l-dvb.
I guess this is all i could contribute to that problem. Thats stuff for 
xfs filesystem experts now..

-Winfried