| Message ID | 4B13F666.7090907@suse.de |
|---|---|
| State | New |
| Headers | show |
On Mon, 30 Nov 2009 22:14:22 +0530 Suresh Jayaraman <sjayaraman@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@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".
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@lithic.org -- http://www.lithic.org 2009/11/30 Jeff Layton <jlayton@samba.org>: > On Mon, 30 Nov 2009 22:14:22 +0530 > Suresh Jayaraman <sjayaraman@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@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@samba.org> > _______________________________________________ > linux-cifs-client mailing list > linux-cifs-client@lists.samba.org > https://lists.samba.org/mailman/listinfo/linux-cifs-client >
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@lithic.org -- http://www.lithic.org 2009/11/30 aaron brick <bricktron@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@lithic.org > -- http://www.lithic.org > > > > > > 2009/11/30 Jeff Layton <jlayton@samba.org>: >> On Mon, 30 Nov 2009 22:14:22 +0530 >> Suresh Jayaraman <sjayaraman@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@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@samba.org> >> _______________________________________________ >> linux-cifs-client mailing list >> linux-cifs-client@lists.samba.org >> https://lists.samba.org/mailman/listinfo/linux-cifs-client >> >
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@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@lithic.org >> -- http://www.lithic.org >> >> >> >> >> >> 2009/11/30 Jeff Layton <jlayton@samba.org>: >>> On Mon, 30 Nov 2009 22:14:22 +0530 >>> Suresh Jayaraman <sjayaraman@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@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@samba.org> >>> _______________________________________________ >>> linux-cifs-client mailing list >>> linux-cifs-client@lists.samba.org >>> https://lists.samba.org/mailman/listinfo/linux-cifs-client >>> >>
On Wed, 09 Dec 2009 10:31:23 +0530 Suresh Jayaraman <sjayaraman@suse.de> wrote: > 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. > With unix extensions enabled, the cost of "serverino" is virtually nil. Without unix extensions there is some cost to fetching server inode numbers, but it shouldn't be too terrible. The main downside to not using server inode numbers is that you can't detect hardlinks. What we're finding though is that there is a lot of server-side bugginess in this area. We've been slowly working on fixes that should make disabling of server inode numbers more automatic. One question I have -- we had some fixes go into the kernel for these sorts of problems very late in the 2.6.32 cycle. If you boot a 2.6.32 kernel (an actual release, not an rc kernel), is this problem still reproducible when you mount w/o "noserverino"?
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;