The code donated by Oracle and Emulex will help safeguard Linux systems against "silent data corruption" - or at least ensure it doesn't go unnoticed.
If you're a Linux sysadmin kept awake at night by the thought of your data going walkabouts, Oracle and Emulex might just have made your day.
According to BetaNews
, the enterprise database and open-source enthusiast Oracle and storage experts Emulex are donating code it's been working on that will attempt to detect and alert system administrators in the case of “silent data corruption
By utilising a metadata store, the technology – which will see integration in the 2.6.27 Linux kernel – will be able to work out if a database is providing inaccurate answers due to data corruption and warn the system administrators via e-mail that they might want to double-check the system for errors.
The code – known as the Data Integrity Extensions, or the rather unfortunate acronym DIE – is based around the T10
Protection Information Model, and represents the first implementation in any operating system thus far. While mostly aimed at enterprise-level database systems, the companies involved are also contributing generic code for supporting data integrity checking at the file system layer, which could be of benefit to all users.
By providing the code under a GPL-compatible licence, the companies are ensuring that no version of Linux will be left behind when it comes to data integrity. Andrew Morton, Linux kernel 2.6 maintainer, has said that the donation of code represents “another example of Oracle's ongoing contributions to better Linux for all users.
The move isn't entirely altruistic on Oracle's part, of course: the company has its own flavour of Linux – called, unsurprisingly, Oracle Linux – which will benefit just as much as any other version, and possibly more when you factor in the draw of support staff who actually wrote the code
. Nevertheless, it's always good to see large companies understanding the draw of the open source world.
Looking forward to better protection for your data, or is this code only likely to affect large-scale database deployments? Share your thoughts over in the forums