-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Fri, 20 Jan 2012 20:06:26 +0100
"ralda@xxxxxx" <ralda@xxxxxx> wrote:
> Hallo Jeff!
>
> > At this point, I'd suggest just setting the cifs_max_pending module
> > parm low (1 or 2) and seeing if that helps. If it does, then that
> > should basically emulate the effect of steve's eventual patch. If it
> > doesn't then we'll probably need to have a closer look at why it isn't.
>
> I have set cifs_max_pending to 2 (setting it 1 results in value 2).
> Giving interesting results:
>
> Normal mount/cp of single file works (same mount parameter as before).
>
> Copying several files with midnight commander showed me a copy speed of
> 4.5 to 5.6 MByte per second - start at 4.5 and raising quickly to 5.6).
> This speed is higher then ever received on copying to the same NAS
> station from same hardware installation. Formerly (kernel 2.6.18
> SMBFS) copies startet below 3.5 MBps and raised slowly up to about 4
> MBps (or slightly above - only at very big files). So reducing the
> setting of cifs_max_pendig not only let the drive work it additionally
> gave me a big step in speed optimization.
>
Not sure why that would be unless requests were sometimes getting
dropped on the floor and the client was occasionally able to recover.
> ... but: Switching virtual console during copy process let the copy
> stop with a stuck mc as before. The only difference: After killing the
> process and a delay of about 2 minutes (felt, not measured) the process
> disappeared and NAS drive returned to a working state without system
> reboot.
>
> If you like/need I may catch more data for diagnosis tomorrow. Just let
> me know what you need and how I shall test. I'm willing to give you all
> data for diagnosis I'm able to collect.
>
This is certainly a very troublesome device :)
I think the existing code is wrong in that it sets the floor value too
high (2 when it should be 1). The problem we get into however is that
when the server can't handle concurrent requests, we must disable
certain features.
We've discussed this on the list before, but we probably ought to do
something like this depending on what the server sends for the maxmpx
value:
maxmpx >= 3: normal operation
maxmpx = 2: disable oplocks, since doing writes while there's still an
outstanding open is problematic
maxmpx = 1: disable sending smb echoes. This does mean that we can't do
detection of unresponsive servers correctly, but there's not much else
we can do at that point.
Steve, what's going on with that patch? It's been many months since we
discussed it last. Do you have anything that Harald can test?
- --
Jeff Layton <jlayton@xxxxxxxxx>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iQIcBAEBAgAGBQJPGcFTAAoJEAAOaEEZVoIVw2kQALVcufVQG1qL6twu/SLbMpgn
YbrYeHF+O+TdsCJxGzBr8+/FZFdGCYIIzrCgiZIwH5Cb38m8URfaikm4qUv7QawX
+pVecmOZeSfLu4DytfsNX7KLisqGfjuHzQc1FnXFTvTgUDwhRdVoKmXIfjIetDIu
cmlAcpaEEfROGOkFb3DNYLP2+Tf+9fgZ0YTJ5vvmzpcK5i18jnmbyBITzmEvBxMl
aAtgLLRrDsbf6ld+rIAnm3FEKcisH702W2Nbn7rF3dGXItt0reDwor8zZPjxFvDn
LCzDfb228ZbenfrIsWAA3ZlFBAJ4qARb76R2Im/0/7z62doFLysS28pI/YV5t17r
rTlc386MFGqa6ffLuEwt49oskNaVwGuqBoZ4OyCYoRjue0uC2zmMAHP7bYdyqrm1
+/9chP0P2VCsxTqzTF1lw7HpZOgfF/08Hr5l+4I/raaSHUyDyhu/gvxuGOHaKRo3
ob8jT55j104sC9WBIDiO0rXuUv0oqgHbBhszduQ2T4MwYjHNlwy5EgA2aRZBvqkq
jeUojXsPd4pjQsNf5Vz1S6RVfHzPDQkrF/O5QPlJaBgTq69PDQCZlxvwb8dmBmhY
n9lkn7KMIs9BmB5XQ6VFbtgIr2FEQzSTb0coe8Vs6dx3D8P2D0tnI20I0WaOk5uF
cBd640zNytbjLTlOlbyO
=IWYp
-----END PGP SIGNATURE-----
ÿôèº{.nÇ+?·?®??+%?Ëÿ±éݶ¥?wÿº{.nÇ+?·¥?{±ýÈ?³ø§¶?¡Ü¨}©?²Æ zÚ&j:+v?¨þø ¯ù ®w¥þ?à2?Þ?¨èÚ&¢)ß¡«a¶Úÿÿûàz¿äz¹Þ?ú+?ù???Ý¢jÿ?wèþf
