Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
SMB2 Corruption issue
Message
From
16/05/2014 14:05:03
 
 
To
16/05/2014 09:00:02
Mike Yearwood
Toronto, Ontario, Canada
General information
Forum:
Visual FoxPro
Category:
Installation, Setup and Configuration
Environment versions
Visual FoxPro:
VFP 9 SP2
OS:
Windows Server 2012
Network:
Windows 2008 Server
Database:
MS SQL Server
Application:
Web
Miscellaneous
Thread ID:
01584063
Message ID:
01600123
Views:
167
A bit of recap for lurkers:

When the "file server DB" SMB2 issue was first reported, the initial workaround was to disable SMB2 entirely. The problem with that is if there are Windows components that rely on it they will no longer work. Also if performance is better using SMB2, if hosts have to fall back to SMB1 then performance may suffer.

As I understand it the Alaska Software MSI does not disable SMB2, it adjusts some of its operating parameters. To me it looks like those changes essentially disable some performance optimizations in favour of improved reliability. So, SMB2 is still available to any processes that need it, and any performance enhancements not disabled by the MSI are still in force.

Having said all that, I don't know how much SQL Server would benefit from, or even use, SMB2:

- Accessing its own database files: for performance reasons those files are usually local (either physically or logically) so SMB (any version) is not involved in their access

- Client communicating with server: that will depend on the protocol(s) used. I haven't looked into this in detail. My understanding is SQL Server used to favour Named Pipes. I don't know if current clients (e.g. Native Client etc.) use something different, or if they still use Named Pipes. Or, how much whichever protocol is used (Named Pipes or something else) depends on SMB.

With client-server data access there is no remote file manipulation - the client isn't creating or working with files on the server, and the server isn't creating or working with files on the client. Two processes are communicating without directly involving the (network) file system. To figure out if SMB2 is better for SQL Server you'd have to determine:

- whether the client-server communications protocol makes use of SMB at all, and if so

- how much of an advantage SMB2 offers over SMB1 for that particular use

>Hey Al
>
>SMB2 seems to benefit single use file access, so would it not aid SQL Server?
>
>>Thanks for the heads-up and link!
>>
>>>FYI everyone - Alaska software has made an msi installer to set/adjust these entries, and it can be removed via Add/Remove programs to undo the change.
>>>
>>>http://www.alaska-software.com/fixes/smb2/overview.shtm
>>>
>>>
>>>
>>>>If your Server and Client OS are at the latest Updates, you can use SMB2 and SMB3 without Problems with DBF Files, if you configure the SMB Parameters:
>>>>
>>>>Windows Registry Editor Version 5.00
>>>>
>>>>[HKEY_LOCAL_MACHINE\system\CurrentControlSet\Services\LanmanWorkstation\Parameters] 
>>>>"DirectoryCacheLifetime"=dword:00000000
>>>>"FileNotFoundCacheLifetime"=dword:00000000
>>>>"FileInfoCacheLifetime"=dword:00000000
>>>>
>>>>
>>>>We have added these REG Keys to our Setup, so we can be safe with SMB2.
>>>>We use this since 2012 an we have no Problems at several Installations / Cusomers.
>>>>
>>>>HTH
Regards. Al

"Violence is the last refuge of the incompetent." -- Isaac Asimov
"Never let your sense of morals prevent you from doing what is right." -- Isaac Asimov

Neither a despot, nor a doormat, be

Every app wants to be a database app when it grows up
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform