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

[aaron brick]

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.

regards and my appreciation!
aaron.

--   aaron brick
--   aaron at lithic.org
--   http://www.lithic.org





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
>>
>