I'm running the Toshiba DT01ACA300 drives mentioned in the report, not had a single one fail over several years of usage. Compare that to the Seagate ST3000DM001, also in that report, I had 10 of them at one point, and over 4 years 90% of them failed (not counting those replaced in the first year under warranty!). They report a nearly 30% failure rate, which is comparable to my experience. Only one Seagate left, and I expect that will be gone within the year (it's got a hot spare waiting to take over when it does).

My Toshiba drives (and a couple of HGST HDS5C3030ALA630, which became the DT01ACA300 Toshibas after the plant transfer to Toshiba) were installed as the Seagates died, have up to 27,700 power on hours (3+ years), and so far flawless reliability. They don't look so reliable in their report, but the failure rate they report is low enough that its not unexpected that I wouldn't have seen one die yet.

I had sworn off Seagates, but it looks like it may have just been one bad model. Useful to see these sort of numbers released as it's helped to remind me not to so easily write off the entire companies drives. Having said that, that specific drive is still available in the retail channel but I wouldn't touch it with a bargepole.

Might be the only way to stop the Met Police thinking they have jurisdiction over the entire country. Then again, they seem to think national borders don't apply to them either for "intellectual property" enforcement, so maybe not.

Exactly right. I'm a Scot who voted no at the last referendum, my decision was never in doubt, and I'm fed up with all the calls to repeat the referendum again. This said the UK exiting the EU would make me strongly reconsider my No vote, and I'd probably support having a new referendum whatever my eventual decision on my vote.

Actually I like the parity declustering idea that was linked to in that article, seems to me if implemented correctly it could mitigate a large part of the issue. I have personally encountered the hard error on RAID5 rebuild issue, twice, so there definitely is a problem to be addressed...and yes, I do now only implement RAID6 as a result.

For those who haven't RTFATFALT (RTFA the f*** article links to), parity declustering, as I understand it, is where you have, say, an 8 drive array, but where each block is written to only a subset of those drives, say 4. Now, obviously you loose 25% of your storage capacity (1/4), but consider a rebuild for a failed disk. In this instance only 50% of your blocks are likely to be on your failed drive, so immediately you cut your rebuild time in half, halving your data reads, and therefore your chance of encountering a hard error. Larger numbers of disks in the array, or spanning your data over fewer drives, cuts this further.

Now, consider the flexibility you could build into an implmentation of this scheme. Simply by allowing the number of drives a block spans to be configurable on a per block basis, you could then allow any filesystem that is on that array to say, on a per file basis, how many disks to span over. You could then allow apps and sysadmins to say that a given file needs to have the maximum write performance, so diskSpan=2, which gives you effectively RAID10 for that file (each block is written to 2 drives, but with multiple blocks in the file is likely to be written to a different pair of drives, not quite RAID10, but close). Where you didn't want a file to consume 2x its size on the storage system, you could allow a higher diskSpan number. You could also allow configurable parity on a per block basis, so particularly important files can survive multiple disk failures, temp files could have no parity. There would need to be a rule however that parity+diskSpan is less than or equal to the number of devices in the array.

Obviously there is an issue here where the total capacity of the array is not knowable, files with diskSpan numbers lower than the default for the array will reduce the capacity, numbers higher will increase it. This alone might require new filesystems, but you could implement todays filesystems on this array as long as you disallowed the per-block diskSpan feature.

This even helps for expanding the array, as there is now no need to re-read all of the data in the array (with the resulting chance of encountering a hard error, adding huge load to the system causing a drive to fail, etc). The extra capacity is simply available. Over time you probably want a redistribution routine to move data from the existing array members to the new members to spread the load and capacity.

How about you implement a performance optimiser too, that looks for the most frequently accessed blocks and ensures they are evenly spread over the disks. If you take into account the performance of the individual disks themselves, you could allow for effectively a hierarchical filesystem, so that one array contains, say, SSD, SAS and SATA drives, and the optimiser ensures that data is allocated to individual drives based on the frequency of access of that data and the performance of the drive. Obviously the applications or sysadmin could indicate to the array which files were more performance sensitive, so influencing the eventual location of the data as it is written.

Tax reasons are probably right. I used to work for Sun in their Scottish manufacturing plant. When we'd order one of our own systems to use in the plants server rooms they would be assembled and tested in the plant, then, rather than roll them 100ft to the server room they were packaged up, put on a truck, driven to the south of England, put on a ferry, driven up to the Netherlands to the distribution center, then driven all the way back again. It took 2 weeks for us to see our systems again! If it was a rush order they would airfreight them to the Netherlands and back.

It wasn't just internal orders either, everything had to go via the distribution center regardless of where it was eventually destined. The reason I was given was "some complex tax thing", don't think anyone there understood it.