[linux-cifs-client] surprise behavior #1: ENOENT for existing directories

[Suresh Jayaraman]

On 12/09/2009 01:07 AM, aaron brick wrote:
> suresh and jeff,
> i am happy to report no such problems since remounting with
> noserverino. this must be some kind of miracle option.
> 
> does it cost much in performance terms to locally assign inode numbers
> like this? i don't know why my NAS is getting them wrong (?), but
> given the results, this is something i really needed.
> 

I don't think there will be an noticable performance impact (though
there might be some impact when generating unique inode number for a
large number of inodes). On the upside a call to the server is avoided.
However, there is no choice but to use 'noserverino' option if the
server doesn't guarantee unique inode numbers.

Thanks,

> 
> 
> 2009/11/30 aaron brick <bricktron at gmail.com>:
>> thank you guys very much for responding to my issues. i have now
>> remounted the share with noserverino. hopefully the problems will go
>> away and in a few days i can come back and tell you so.
>>
>> cheers!
>> aaron.
>>
>> --   aaron brick
>> --   aaron at lithic.org
>> --   http://www.lithic.org
>>
>>
>>
>>
>>
>> 2009/11/30 Jeff Layton <jlayton at samba.org>:
>>> On Mon, 30 Nov 2009 22:14:22 +0530
>>> Suresh Jayaraman <sjayaraman at suse.de> wrote:
>>>
>>>> On 11/30/2009 06:53 PM, Jeff Layton wrote:
>>>>> On Mon, 30 Nov 2009 16:45:59 +0530
>>>>> Suresh Jayaraman <sjayaraman at suse.de> wrote:
>>>>>
>>>>>> On 11/30/2009 07:46 AM, aaron brick wrote:
>>>>>>> i am having two intermittent problems with CIFS and am sending
>>>>>>> separate emails to the list for each. this paragraph is identical. my
>>>>>>> desktop runs debian and kernel 2.6.32rc7; i am mounting a filesystem
>>>>>>> from my synology NAS, running DSM 2.2-0942 and using ext3 & RAID5
>>>>>>> internally. the link is gigabit through cat5e and a netgear switch.
>>>>>>> the only CIFS dmesg entry i see is a couple of: "CIFS VFS: server
>>>>>>> 10.1.1.2 of type Samba 3.2.8 returned unexpected error on SMB posix
>>>>>>> open, disabling posix open support. Check if server update available."
>>>>>>> (FWIW, synology hasn't released a firmware with a more recent samba.)
>>>>>>>
>>>>>>>
>>>>>>> here, creating files within a directory sometimes fails with ENOENT as
>>>>>>> if the parent did not exist. this generally prevents me from using the
>>>>>>> shared filesystem for compilation. an example follows:
>>>>>>>
>>>>>>>
>>>>>>> 11:08 / > mount | grep nas
>>>>>>> //nas/data on /data type cifs (rw,mand)
>>>>>>> 11:08 / > cd data
>>>>>>> 11:08 /data > mkdir a
>>>>>>> 11:08 /data > mkdir a/b
>>>>>>> mkdir: cannot create directory `a/b': No such file or directory
>>>>>>> 11:08 /data > strace mkdir a/b |& grep mkdir
>>>>>>> execve("/bin/mkdir", ["mkdir", "a/b"], [/* 22 vars */]) = 0
>>>>>>> mkdir("a/b", 0777)                      = -1 ENOENT (No such file or directory)
>>>>>>> write(2, "mkdir: ", 7mkdir: )                  = 7
>>>>>>>
>>>>>>
>>>>>> I have not been able to reproduce this 2.6.31-rc1 against Samba 3.2.7. But a
>>>>>> quick look at the code suggests there could be a problem if we do this
>>>>>> sequence:
>>>>>>
>>>>>> POSIX open against Samba server < 3.3.1 (tcon->broken_posix_open will be set)
>>>>>> followed by a mkdir (will call CIFSPOSIXCreate). As we don't seem to check
>>>>>> whether the broken_posix_open is set, this might have led to this issue I think.
>>>>>>
>>>>>> Does the following patch (a quick, untested) fix the issue?
>>>>>>
>>>>>>
>>>>>>
>>>>>>  fs/cifs/inode.c |    3 ++-
>>>>>>  1 files changed, 2 insertions(+), 1 deletions(-)
>>>>>>
>>>>>> diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
>>>>>> index cababd8..f1e9ab6 100644
>>>>>> --- a/fs/cifs/inode.c
>>>>>> +++ b/fs/cifs/inode.c
>>>>>> @@ -1038,7 +1038,8 @@ int cifs_mkdir(struct inode *inode, struct dentry *direntry, int mode)
>>>>>>            return rc;
>>>>>>    }
>>>>>>
>>>>>> -  if ((pTcon->ses->capabilities & CAP_UNIX) &&
>>>>>> +  if (!tcon->broken_posix_open && tcon->unix_ext &&
>>>>>              ^^^^ should be "pTcon"
>>>>>
>>>>
>>>> Oops, sorry about the not even compile tested patch. Here is the
>>>> compile tested patch. Could you please test this one?
>>>>
>>>>
>>>>  fs/cifs/inode.c |    3 ++-
>>>>  1 files changed, 2 insertions(+), 1 deletions(-)
>>>>
>>>> diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
>>>> index cababd8..31be938 100644
>>>> --- a/fs/cifs/inode.c
>>>> +++ b/fs/cifs/inode.c
>>>> @@ -1038,7 +1038,8 @@ int cifs_mkdir(struct inode *inode, struct dentry *direntry, int mode)
>>>>               return rc;
>>>>       }
>>>>
>>>> -     if ((pTcon->ses->capabilities & CAP_UNIX) &&
>>>> +     if (!pTcon->broken_posix_open && pTcon->unix_ext &&
>>>> +         (pTcon->ses->capabilities & CAP_UNIX) &&
>>>>               (CIFS_UNIX_POSIX_PATH_OPS_CAP &
>>>>                       le64_to_cpu(pTcon->fsUnixInfo.Capability))) {
>>>>               u32 oplock = 0;
>>>
>>> Now that I think about it though...
>>>
>>> The whole broken_posix_open thing was not a problem for actual creates,
>>> just when opening existing files. I'm pretty sure we still want to use
>>> posix creates for mkdir even if broken_posix_open is set.
>>>
>>> I'm more interested to know whether both of these problems go away if
>>> he mounts with "noserverino".
>>>
>>> --
>>> Jeff Layton <jlayton at samba.org>
>>> _______________________________________________
>>> linux-cifs-client mailing list
>>> linux-cifs-client at lists.samba.org
>>> https://lists.samba.org/mailman/listinfo/linux-cifs-client
>>>
>>


-- 
Suresh Jayaraman