[linux-cifs-client] Problem with stat() on CIFS.

Suresh Jayaraman sjayaraman at suse.de
Fri Dec 18 00:01:18 MST 2009


On 12/17/2009 07:30 PM, Jeff Layton wrote:
> On Thu, 17 Dec 2009 15:07:54 +0530
> Suresh Jayaraman <sjayaraman at suse.de> wrote:
> 
>> On 12/17/2009 09:05 AM, Bart Oldeman wrote:
>>> Hi,
>>>
>>> on 32-bit systems using plain stat() (not stat64()) is problematic on
>>> CIFS mount points (kernel 2.6.32):
>>>
>>> $ stat /home/bart/cifs
>>>   File: `/home/bart/cifs'
>>>   Size: 0               Blocks: 0          IO Block: 16384  directory
>>> Device: 11h/17d Inode: 8839049314305  Links: 1
>>> Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
>>> Access: 2009-12-16 22:14:55.000000000 -0500
>>> Modify: 2009-12-16 22:14:00.000000000 -0500
>>> Change: 2009-12-16 22:14:00.000000000 -0500
>>>
>>> As you can see the inode number is very high: 0x80a00650001
>>> Glibc's stat() calls the kernel's stat64(), tries to convert the
>>> struct stat64 structure to a "struct stat" and fail.
>>>
>>> Note that I've only seen this with a Samba server when Unix extensions
>>> were NOT enabled -- if they are enabled I get 0x650001 as the inode
>>> number which is OK.
>>
>> I managed to reproduce this, but it is not clear to me what is the
>> expected behavior esp. with various combination of nounix and serverino
>> mount options.
>>
>> I think this is what is happening:
>>
>> With "nounix" mount option or unix extentions disabled (and serverino
>> option being default) against Samba server, cifs client tries to send a
>> QUERY_PATH_INFO with ALL_INFO interest level (which doesn't seem to have
>> a place holder for unique inode number). It then tries to send a
>> QUERY_FILE_INFO request with FILE_INTERNAL_INFO interest level to get
>> the Server inode number and it gets the unique Id (IndexNumber) wrong
>> here. Whereas when unix extension is enabled, the client gets the unique
>> inode number as part of the response to QUERY_PATH_INFO with
>> FILE_UNIX_BASIC level of interest.
>>
>> Is the client expected to get the server inode number from the server if
>> Unix extensions is disabled? If yes, it appears to me that the Samba
>> server (3.2.4 in my case) when unix extension is disabled is not sending
>> the Server inode number correctly. Or perhaps QUERY_FILE_INFO with
>> FILE_INTERNAL_INFO level of interest is not the right way to get the
>> server inode number (I couldn't find any documentation on this).
>> I think this issue had been there for long has been exposed now by
>> making serverino as default.
>>
>> Is your server guaranteed to return unique inode numbers? If not as a
>> workaround, try mounting with "noserverino" mount option and see whether
>> the problem goes away.
>>
> 
> It doesn't get the uniqueid wrong here, it's just that the uniqueid is a
> different value from the inode number. With samba, the "UniqueID" is a
> fusion of the device ID and inode number. That value is supposed to be
> unique over the scope of the entire server whereas inode numbers are
> only unique over the scope of a single filesystem.
> 
> When mounting with POSIX extensions we use the actual inode number
> provided by the POSIX calls as an inode number. When mounting without
> them, we don't have a way to get that so we use the uniqueid.
> 
> UniqueID's are very often greater than 2^32 however, so that value
> often happens to run afoul of glibc's trickery here. The real fix is to
> make sure that you compile your programs with LFS support
> (i.e. with -D_FILE_OFFSET_BITS=64).

Jeff, thanks for the great explanation. However, I find no documentation
(atleast user/administrator level) about this in mount.cifs man page
(and no mention about nounix mount option as well). Would it help to add
this piece of information to mount.cifs man page as the change (UniqueId
instead of inode numbers) is visible to users. If yes, I can send a
documentation patch.

Thanks,

-- 
Suresh Jayaraman


More information about the linux-cifs-client mailing list