Modern operating systems work well when installing a new SSD. Years ago this was not true since SSDs were new and exotic. As 2014 comes to a close, most modern operating systems are able to quickly setup SSDs with the correct alignment/ offset for them to work at peak performance. Having the correct alignment/ offset when setting up a SSD was previously a significant issue. Computers and operating systems, for years, have used rotating storage as their default medium. When the hard drive manufacturers moved to larger disks, necessitating 4K block sizes over 512B block sizes we saw some of those assumptions being tested. While having a misaligned hard drive can cause performance issues, solid state drives can suffer other drawbacks. One example of this is that improper alignment/ offset can cause excess writes to the underlying NAND, thereby decreasing performance and effective write endurance.
As part of our SAS SSD quick benchmarking we recently looked at the Seagate 1200 400GB SAS SSD. In the test bed we were, of course, testing the 200GB parts. We picked one of the Seagate 200GB SAS SSDs and saw this graph after conditioning but upon the AS SSD benchmark run on our 6gbps SAS2 controller under Windows Server 2012 R2:
Clearly something as amiss. Luckily we had the second Seagate 1200 200GB drive on the same controller and saw much higher performance. One can see in the screenshot that the 4K-64Thrd numbers look about right but the sequential numbers are significantly off. We found that the drive alignment/ offset was a big factor in this performance difference.
The lesson here is that it does pay to spend a few minutes running fast benchmarks on new drives. Long sessions like we are running with iometer on these drives (and as we previewed in our Intel S3700 100GB v. 710 100GB quick benchmarks recently) are usually not necessary to check that drives are working properly.
The fix was simple, we deleted partitions and re-initialized drives. The net impact is that the 200GB Seagate 1200 SAS SSDs were working properly again and ready for single drive and RAID testing once the offset was fixed.
Except you can see right in the AS-SSD screenshot that BOTH drives do appear to be aligned, albeit to different offsets.
SSD #2 has the partition offset by 1024KiB, which should be fine (I have no idea what is causing the problem, but it does not appear to be partition alignment).
SSD #1 has the partition offset by 132,096KiB, which should also be fine (132096 = 4 x 33024)
John, I’d agree although we usually say offset and alignment go hand-in-hand
I’d expect the 1024 to be fine but we’ve seen this sort of issue crop up before. Your end advice is right though —- always do a fast check for performance. John points out that the alignment should be right but the one the tool says is right and we behold terrible results.
Great tip on a best practice.
With Manf. specifications often not being exactly honest or spot on (Lets blame that on compression, wear, non-zeroed blocks and the time of the day) I can see this generating false positives. Wouldn’t it be better to check for alignment rather than the symptons of misalignment?
“The fix was simple, we deleted partitions and re-initialized drives”
This I find bloody annoying, this might be simple to say but when you haven’t provided much info, it is pissing in a pocket.
The screenshots were Windows and the article says Windows Server 2012 R2. Just go to partition manager (Hit start and type partition) and then you are like 5 clicks away. Delete partition. Then right click on the allocated space and new volume. The rest is all in a wizard. One of the most basic things to do in microsoft’s newer oses.
Mike you’re right but I’d still do the benchmark. You’d want to do both ideally like ChrisS says..
I’m not sure what you mean by “offset and alignment go hand-in-hand”. Alignment in this context refers to the offset of the partition from the beginning of the device.
AS-SSD is giving the partition offset from the beginning of the device of the partition it is testing, in KiB.
Performance of some SSDs is much better when the offset is equal to the internal SSD page size. Common SSD page sizes are 4KiB, 8KiB, 16KiB.
Since the 1024KiB offset (shown in the first AS-SSD screenshot) is a multiple of all of those, it is clear that the alignment is fine.
Since the performance is lower than expected, the conclusion is that something other than alignment is responsible for the lower performance. It could be any of a number of things, just not alignment.
…and it has been determined that NAND PAGE SIZE and ERASE BLOCK SIZE should also be used when determining the proper partition alignment for SSDs. If, in this example, by sheer luck the figure that was arrived at and used to base alignment on was actually compatible with these NAND properties then the next procedure in line to attempt resolution would be a secure erase of the ssd device and then re-partitioning. If the problem persisted I would replace the cable with a known good cable and if that was unsuccessful then the device would go by the route of an RMA (especially if the same model of drive, with the same configuration would perform nominally after being installed onto the same channel). In this case my guess was that what ever procedure was used to “re-initialize” the problem device resulted in the equivalent of a secure erase.