... or me dumb, me still winz :>
Story mode on
In short, this post is about how I've managed to run stock SATA disks in an EMC array.
I should have written this post a long time ago but I simply forgot about it - lecithin deficiency? or whiskey overload? I don't know :D
Maybe someone finds it useful though, plus, after few years I can call it a retro hack lol
Around 2011 I was working at a data center. One of my friends had a problem with, already old at that time, CLARiiON AX4-5 storage array by EMC - failing disk obviously.
Since this is a quite a simple SATA storage, we wanted to swap disks with other of the shelf SATA disks.
The problem was that an array would not accept any stock disk and throw an error saying "drive not supported" instead.
My friend then formatted an original drive under some sort of SATA low-level format tool but that didn't help and he managed to brick it during that process.
Quick EMC support call revealed that we HAVE to buy super special disk drives that are pre-formated for this array in a production process.
Shall I add that these "special" disks were ten times more expensive? :D
An array was loaded with 1TB SATA disks - Seagate Barracuda ES.2 series. By a coincidence, I had a 1TB drive on my desk of that same type and series but without a sticker "EMC super special drive for CLARiiON WTFOMGLOL v.14". That was the same model as the one in an array - ST31000340NS. It wasn't working with an array and of course, that was the first hint ...
Story mode off
At the beginning, I had to dump a binary copy of the working/EMC supported disk to an image file.
I've used a typical USB->SATA adapter and obviously Linux dd command to achieve this (bs=8M to speed it up a little)
dd if=/dev/DISK of=diskdump.img bs=8M
The first and most confusing part after ripping the whole disk to a binary image was a "fake" 520 sector size.
520 sector size is used by some SCSI controllers to keep integrity info along with data in one sector.
512 bytes of normal data and 8 bytes of error correction data. Here is a nicely written wrap-up about sector sizes and other intresting stuff.
This is key info from a link above.
Some formatting structures can also include error correcting information in the sectors, which manifests itself in the disks being low-level formatted with 520 or 528-byte sectors. In this case, the sector still has 512 bytes of user data. Neither Windows nor Linux supports this directly, although i5OS (IBM iSeries) and various SAN controllers do.
Another piece of the puzzle was found in disks datasheets. SATA drives ALWAYS have 512-byte sector set as a base and cannot be low-level formatted to any other sector size - hence 520-byte fakeness.
I assumed it is a software/firmware solution.
Anyway, it indeed looked like a 520 sector mask put on a 512 sector disk so obviously, as my first attempt, I tried to mimic original EMC disk format. I've carved an empty first 520-byte sector out of an image dump. Notice a highlighted part that serves as a separator
Then I wrote a super lame and inefficient bash script that simply writes this sector(file) all over stock SATA drive. (scripts link on a bottom of this post)
It took a while but I had other things to do so I've left it to run for a couple of hours.
No surprise, this approach didn't work at all. It was rather a blind shot and it failed miserably :D
Maybe disk firmware then?
At this point, I decided to work a bit on disks firmware and try to dump some info about mysterious EMC hacks that prevent regular SATA disk from running. It wasn't quite logical because as I wrote above, my friend at a data center managed to "brick" working disk with some sort of low-level format.
Anyway, I was clueless at that moment so I gave it try. I also wanted to learn something new.
I've tested tons of low-level software tools and didn't find a tiny bit of info about EMC. That surprised me.
Then, all of sudden, in a small room where you can hear only "PLAAP" sounds from time to time ... a new clue was born ...
I've come to a conclusion that some sort of metadata that identifies a disk as EMC usable, has to be written somewhere on a disk itself. Where would you put it ??
Of course !!! at the end of the disk - last sector to be exact.
I was like...
In order to dump the last sector, I had to know an exact number of sectors and then dump it with a dd command on a Linux box.
I've used a small script that I wrote during this project. It shows a number of 512 and 520-byte sectors.
Nothing fancy, it can also be achieved by issuing:
fdisk -l /dev/DISK
Then, I've run following command:
dd if=/dev/DISK of=lastsector.bin bs=512 skip=1953525167
where skip param holds last sector number of the disk.
It skips all sectors of an input (a disk) and dumps only the last sector.
... and viola! There it is! The mysterious metadata!
I've then dumped last sectors of few other legit disks and figured out that dumps differ only with the serial number.
I didn't even bother to supply a proper serial number to test if this simple 512-byte chunk is enough to heal a previously "bricked" by my friend disk. Instead, I've just put a random data in place of an original serial just to make sure it is unique and differs from other serials. I've used a simple hex editor to achieve it.
Then I had to write a modified 512 file to the last sector of a disk. Another dd was issued:
dd if=lastsectorMODIFIED.bin of=/dev/DISK bs=512 seek=1953525167
Seek param holds last disk sector number. I've used SEEK because this time it is on an output so we are not skipping an input stream but seeking to write in an output.
Next, I've put the disk inside an array aaaaaaand .....
It worked flawlessly. When I finally had the procedure figured out, I was able to write metadata with changed serial numbers to stock(cheap) SATA disks and an array started to work without a problem.
Now you can safely watch an AMIGAAAH demo ;)
Cheers and see you next time.