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.
Cool, but I don’t quite understand this bit:
ReplyDelete“…………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'.?
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.
ReplyDelete