Re: surprise behavior #1: ENOENT for existing directories
Suresh Jayaraman <[email protected]>
| Newsgroups | gmane.linux.file-systems.cifs |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]>: >> 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 >> -- [email protected] >> -- http://www.lithic.org >> >> >> >> >> >> 2009/11/30 Jeff Layton <[email protected]>: >>> On Mon, 30 Nov 2009 22:14:22 +0530 >>> Suresh Jayaraman <[email protected]> wrote: >>> >>>> On 11/30/2009 06:53 PM, Jeff Layton wrote: >>>>> On Mon, 30 Nov 2009 16:45:59 +0530 >>>>> Suresh Jayaraman <[email protected]> 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 <[email protected]> >>> _______________________________________________ >>> linux-cifs-client mailing list >>> [email protected] >>> https://lists.samba.org/mailman/listinfo/linux-cifs-client >>> >> -- Suresh Jayaraman