Code Change Request

# 101

Back to Code Changes

Christopher
Technical Support
StableBit DrivePool
2.0.0.420
Windows Server 2012 R2
Public
Alex

Ported back fix to 1.3.6.7579.
Public
Alex

This one was horrendously complex.

There were a number of issues with how we processed byte locks with regards to Hyper-V. The worst of them was that our file system didn't always release byte locks immediately after the last handle was closed to a file, the locks were released some time later by the OS. This is documented on MSDN (and in other places it's contradicted). In any case, NTFS doesn't do this so we don't do this as well. A few other, more obscure, and more specific issues were identified and fixed as well.

This batch of fixes has potential impact on other issues that have been reported. For example, I've verified that with the new fixes VHDs can now be created and mounted on the pool. I would imagine that other applications that rely heavily on byte range locks would be similarly affected.

Take note that byte range locks are not the same thing as oplocks or the internal file system locks:
  • Byte range locks are used to synchronize file access among multiple processes.
  • Oplocks ensure data consistency over a network and are an optional optimization. They are also used by anti-virus software (and StableBit DrivePool) to delegate access to files.
  • The internal locks of a file system are in use at all times to ensure data consistency.
The full change log follows:


* [D] [Issue #101] The context of a byte range lock request is not always the current thread. (E.g. Hyper-V)
* [D] [Issue #101] FileObject->LockOperation seems to be inconsistent, switched to internal flag.
* [D] [Issue #101] Byte range locks were not being released immediately on file close. Oddly, this is exactly 
                   the expected behavior according to MSDN 
                   ( http://msdn.microsoft.com/en-us/library/windows/desktop/aa365715 ): "If a process terminates 
                   with a portion of a file locked or closes a file that has outstanding locks, the locks are 
                   unlocked by the operating system. However, the time it takes for the operating system to unlock 
                   these locks depends upon available system resources." Unfortunately this was creating a number 
                   of issues.
Public
Alex

HyperV will not create VMs on the pool.