Re: Re: [PATCH] cifs: fix fh_mutex locking in cifs_reopen_file

Jeff Layton <[email protected]>
Newsgroups gmane.linux.file-systems.cifs,gmane.network.samba.internals,gmane.linux.kernel
Message-ID <[email protected]>
On Sun, 2009-06-28 at 14:02 -0500, Steve French wrote:
> On Sun, Jun 28, 2009 at 11:43 AM, Steve French<[email protected]> wrote:
> > On Sat, Jun 27, 2009 at 8:23 PM, Jeff Layton<[email protected]> wrote:
> > In any case, as long as we are sure we are hitting a Samba server
> > limit (or server side
> > per-process limit), we are ok and can continue to review/merge the very large
> > inode patches.  I am verifying with one additional pair of temporary
> > stats (counters of successful opens) in the exit path of cifs_open and
> > cifs_close)
> > to make sure that those match what I have already verified that we are seeing
> > with smbstatus and the client side counters on number of successful posix_opens.
> 
> I am puzzled about the Samba 3.4 max files limit (I am seeing it at
> 1014 opens) and seems
> strange that dbench would open so many files, but with counters in
> cifs_open and cifs_close - I see 1014 more opens than closes (from the vfs)
> which matches what I see at the SMB level and what I see in Samba server.
> dbench 4 fails even faster.   This also fails on other OS (opensuse,
> Ubuntu etc.),
> but worked on Samba 3.0.28.  Is it possible that Samba 3.4 changed their
> max open file limit?
> 
> 

Doesn't 3.0.28 have broken POSIX open calls? That may account for the
difference. I can't be certain I was seeing the same failures you were
with dbench, but I never got a passing run until I applied that patch to
fix the reopen locking.

-- 
Jeff Layton <[email protected]>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.