For Filer CIFS, when concurrently several clients open the same file, then thees clients (all these clients have write access on the file) try to modify and write to this file differently almost at the same time. What will happen to this file? Which client will have the final right to have the file modified?
Thanks for help!
For Filer CIFS, when concurrently several clients open the same file, then thees clients (all these clients have write access on the file) try to modify and write to this file differently almost at the same time. What will happen to this file? Which client will have the final right to have the file modified?
Generally speaking, the application instance that writes last within a set of bounds will get to take home the cheese, but this is precisiely the type of thing that concurrency controls exist to manage. If multiple instances of an application need to share/modify a single file in a cooperative manner, the app should be using Win32 CreateFile() share modes, and functions like LockFile() & LockFileEx() to avoid deadlocks, file corruption, and any of the other nasty things that can happen when apps that weren't designed to share common file spaces try and do so.
Data ONTAP supports all of these standard mechanisms on the Windows/CIFS side, and even extends them across into the NFS space using a technology called SecureShare. The protection mechanisms are designed to preserve data integrity by ensuring that when locking semantics conflict between the different locking protocols/paradigms, the "path taken" will be the behaviour that would prevent corruption, or potential corruption from occuring.
Keith
Generally speaking, the application instance that writes last within a set of bounds will get to take home the cheese, but this is precisiely the type of thing that concurrency controls exist to manage. If multiple instances of an application need to share/modify a single file in a cooperative manner, the app should be using Win32 CreateFile() share modes, and functions like LockFile() & LockFileEx() to avoid deadlocks, file corruption, and any of the other nasty things that can happen when apps that weren't designed to share common file spaces try and do so.
Expanding on what Keith said:
If the applications opening the file open it for reading and writing, or for writing, with "deny write" or "deny read and deny write" share modes, whichever application's open request gets processed first by the filer will succeed, and the other open requests will *fail*, so that the other two clients won't be *allowed* to write to the file. That's an example of concurrency control.
I suspect many applications will do that, so that only one of them will get any rights at all to write to the file.
If an application tries to open it for reading and writing, or for writing, *without* "deny write", then:
if somebody already has it open with "deny write", the attempt will fail, and the application opening without "deny write" will fail;
if nobody has it open with "deny write", the attempt will succeed (assuming the user has permission to write to the file).
If multiple applications have the file open for writing - this means none of them opened it with "deny write" - they *all* have the write to modify the file. In that case, a particular region of the file will contain whatever was last written to that region. If they all try to write to a given region, whichever write request is processed last by the filer will be the one whose data appears in that region of the file.
Note that all of this applies even for multiple programs running on the *same* Windows machine, accessing files on that machine's local disk, and also applies with other CIFS servers, e.g. the CIFS server code on various versions of Windows.
-
Guy Harris -
Jay Yau -
Keith Brown