Re: cifs large write performance improvements to Samba

From: bert hubert
Date: Wed Dec 22 2004 - 09:58:24 EST


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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/