linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: bert hubert <ahu@ds9a.nl>
To: Steve French <smfrench@austin.rr.com>
Cc: linux-cifs-client@lists.samba.org, linux-kernel@vger.kernel.org
Subject: Re: cifs large write performance improvements to Samba
Date: Wed, 22 Dec 2004 15:56:28 +0100	[thread overview]
Message-ID: <20041222145628.GA5727@outpost.ds9a.nl> (raw)
In-Reply-To: <41BDC911.9010600@austin.rr.com>

On Mon, Dec 13, 2004 at 10:53:37AM -0600, Steve French wrote:
> 
> The current mainline (very recent 2.6.10-rc Linux tree) should be fine 
> from memory leak perspective.  No such leaks have been reported AFAIK on 
> current cifs code and certainly none that I have detected in heavy 
> stress testing. 

Indeed, thank you Steve! I had not noticed this progression from the
changelog messages. I've since verified on a multimillion file share that
cifs indeed shrinks the cifs_inode_cache under memory pressure. I've turned
on updatedb again, hope that the box survives it now.

> On the issue of regressing back to smbfs :)  There are a few things 
> which can be done that would help.

I've since moved some stuff back to cifs to see what happens. I'll try to
convince some other people so they can share/report their problems properly.

> 2) Public view of the status of testing - the raw data needs to be 
> posted regularly as kernel updated (and against five or six different 
> server types) so users see what is broken in smbfs (and so users can see 
> what posix issues are still being worked on cifs and any known 
> problems).   smbfs fails about half of the filesystem tests that I have 
> tried, due to stress issues, or because the tests requires better posix 
> compliance or because of various smbfs stability fixes.

That may be so but the definite perception is that cifs is unstable compared
to smbfs. Then again, this may have been related to out of memory conditions
which generaly tend to make things suck.

Thanks for your thoughtful reply, I'll see if I can provide useful feedback.

Regards,

bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO

  parent reply	other threads:[~2004-12-22 14:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-13  5:45 cifs large write performance improvements to Samba Steve French
2004-12-13 14:38 ` bert hubert
     [not found]   ` <41BDC911.9010600@austin.rr.com>
2004-12-22 14:56     ` bert hubert [this message]
2004-12-13 16:56 Steve French
2004-12-13 17:20 ` cliff white
2004-12-13 18:34   ` Steve French
2004-12-13 18:43     ` Steve French
2004-12-16 12:11       ` Marcelo Tosatti
2004-12-16 18:58         ` Hans Reiser
2004-12-16 16:30           ` Marcelo Tosatti

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20041222145628.GA5727@outpost.ds9a.nl \
    --to=ahu@ds9a.nl \
    --cc=linux-cifs-client@lists.samba.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=smfrench@austin.rr.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).