third_party_content:sprezz_blog:17673.6666666667

Linear Hash Rehashed

Published 20 MAY 2016 at 04:00:00PM by Sprezz

In what has been one of the most exciting announcements since the trailers for OI 10, Revelation Software have just released UD 4.7.2 and 5.0.0.4. Whilst the small incremental release number might make this seem insignificant it actually marks one of the biggest changes in linear hash since the Universal Driver was released.

For some time now we have been aware of issues with "enterprise" sites where under certain ill-defined circumstances, the network would crawl to a halt and frustrated users would sit helpless until the system eventually recovered. Under certain extreme conditions the system would never recover and the only solution would be to reboot the server with possible ensuing data corruption. After such halts linear hash files would be seen to have "exploded". Growing in size from tens of megabytes to tens of gigabytes.

The suspicion has long been that some form of alpha corruption led to a massive resizing exercise and that this in turn led to the network slowdown.

With the help of a large UK client Revelation staff have finally been able to track this error down and to finally fix it! And while they were under the hood they've made a whole slew of other changes that make fine tuning an enterprise system so much easier!

VSS has been made more reliable.

Resizing has been made programmatically controllable. So a site that experiences peak transaction volumes at specific times can now tell the UD not to do any resizing until it is appropriate to do so. The underlying filing system naturally copes well with this and when the resizing is re-enabled  it can catch up with the necessary tasks.

Size-locking has been revisited and fixed. We have an unpublished blog article about how size-locking was broken in later releases of OI - which made it very difficult to control whether files expanded/contracted or not. This has now been fixed and even better enhanced so that it works with the hidden volume/share feature of the UD so the client no longer needs physical access to the file to set the size-lock.

The UD can now reliably be shut down even if clients are not responding. This fixes an issue where the UD would refuse to close and the server would have to be rebooted to force closure.

A new registry flag has been added called CreateFileFlags. The service expects that, if this registry entry exists, it has a DWORD value. If it’s not set, its default value is the value associated with:

FILE_ATTRIBUTE_NORMAL | FILE_FLAG_RANDOM_ACCESS | FILE_FLAG_OVERLAPPED (which evaluates to 0x50000080)

So the developer can now ensure that writes are passed straight through to the disk and not cached. See the Microsoft documentation here.   Not forgetting the fact that the UD now supports encryption AND reestablishing dropped connections!

All of us at Sprezzatura salute Revelation for the mammoth efforts they invested into putting this right - along with grateful thanks to the UK client who made this possible.

Comments

Comment by Barry Stevens on 22 MAY 2016 at 10:40:27PM:

Cool, but I don’t quite understand this bit:

“…………A new registry flag has been added called CreateFileFlags. The service expects that, if this registry entry exists, it has a DWORD value. If it’s not set, its default value is the value associated with:

FILE_ATTRIBUTE_NORMAL | FILE_FLAG_RANDOM_ACCESS | FILE_FLAG_OVERLAPPED (which evaluates to 0x50000080) So the developer can now ensure that writes are passed straight through to the disk and not cached.”

So the default is cached OR passed through.?

So the developer 'can be ensured that it is not cached' *OR* 'the developer can ensure it is not cached by setting himself'.?

Comment by Sprezz on 11 APR 2018 at 11:42:41AM:

Sorry for some reason we didn't get a notification of your comment! Per the docs there is a specific flag you need to set to ensure it isn't cached. The FILE_FLAG_WRITE_THROUGH flag. As you can see above that ISN'T set so the default is to cache.

Original ID: post-8910546182600137268
  • third_party_content/sprezz_blog/17673.6666666667.txt
  • Last modified: 2024/01/17 19:45
  • by 127.0.0.1