As I understand it, the well known consistency problems starting with SMB2 for file server / ISAM DB mostly stem from an added client side buffer not synched often/fast enough.
The performance/update parameters led more than a measily few to realize that running server ISAM under SMB2 can evoke inconsistencies in DB.
Even before that, both server and client had (other) caches, which were synched through OpLocks.
At least SOME ran into trouble under SMB1 with enabled oplocks in NT4/W2K/XP-generation OS.
http://www.superbase.com/services_tech_support_oplocks.htmServer side SMB2 has to run as well, otherwise client SMB will downgrade to minimum common denominator.
IIRC server side changes in SMB2 were some way of dynamic resource shaping depending on latest traffic.
No linkable "idea" if server side buffers were added or changed, but resource shaping hints at such animals ;-)
>It appears FLUSH help his situation.
>Does SMB2 run on workstation or just server?
>>But later OS do not respect such flushing if SMB2/oplocks is in the loop.
