SSD alignment

[Meghan54]

Question.....when you booted with the Win 7 DVD, you got to here, right? And you chose the Custom option like shown below, right?

So, the next screen should have looked something like this, considering you've already had the drive in use:

And you chose the format option. Ever notice the delete option? That's what to choose to delete the partition(s) on the hard drive, esp. if you want Win 7 to align the SSD properly. Then, once the partition(s) is/are destroyed, click New, choose how to partition on the screen that opens (sizes), then format.

No clusterf**k found.


And if you end up with this screen, simply click on the Advanced options to give you the above noted screen.

Crap, both my now departed 83 y.o. father-in-law and my 58 y.o. wife both figured it out on their own.

 

[DownTheSky]

There's a program called "SSD alignment tool" that does just that. You won't have to reinstall Windows and you won't lose any data. :thumbsup:

 

[hackerballs]

Except the "XP awesomness" will be short lived with support from MS going, going, gone.

Must be a name for someone who will not progress anymore and starts to just ride on what is old....................LOL, It's Grandpa,

just kiddin' grandpa

And all MS window disks gave you option of creating as many partitions as you like during install. The point being with a SSD, this need not be done with the OS boot SSD, use another HDD/SSD and partition the crap out of it if you like

 

[John Connor]

There's a program called "SSD alignment tool" that does just that. You won't have to reinstall Windows and you won't lose any data. :thumbsup:

I can't find that in Google. Can you provide a link?

Edit- Are you referring to Paragon Alignment Tool?

 

[John Connor]

hackerballs your name should be hack your balls. LOL!

 

[glugglug]

Except the "XP awesomness" will be short lived with support from MS going, going, gone.

Well, Windows 7 "end of support" is currently Jan. 2015, only 16 months away.
Microsoft is really trying to steamroll everyone into Win8. I suspect there will be enough pushback that they have to extend the Win7 support like they did for XP, but who knows....

 

[glugglug]

So, the next screen should have looked something like this, considering you've already had the drive in use:

Protip: while searching for solutions to my USB issues during Win8 install and for how to do a custom cluster size before reinstall I ran across this:

http://forums.storagereview.com/index.php/topic/29019-formatting-the-ssd-to-64k-cluster-sizes/

So I now have my Neutron 512GB formatted with 16KB clusters to match the SSD page size. If anyone has a good benchmark to run I can get some numbers, I would wager that the random reads and writes (especially writes) will be substantially better than with the default 4KB.

Also, with most RAID controllers, any sort of striped RAID (0,5,6,10) will benefit from 64KB cluster size. Although then you might have a ton of wasted space from partially used clusters.

 

[hackerballs]

John Conner
While the name "hackerballs" might look weird at first glance, the reason behind it makes perfect sense. Has nothing to do with internet/pc's. It stems from EA TigerWoods golf. I could not think of a better way to describe my swing. Then I just kept the name going as it seems to bug people. The same way the profile pic seems to get people upset.

All for fun

 

[GlacierFreeze]

So I now have my Neutron 512GB formatted with 16KB clusters to match the SSD page size. If anyone has a good benchmark to run I can get some numbers, I would wager that the random reads and writes (especially writes) will be substantially better than with the default 4KB.

Try AS SSD Benchmark and HDTune. I'm sure there are others that some like, but those 2 are just off the top of my head. I'm interested in seeing the numbers too.

 

[John Connor]

Or ATTO.

 

[John Connor]

Well, I just ran Paragon Alignment Tool with the safeest modes on so that I wouldn't loss data and it aligned my SSD. Check out the results. I'm using SATA II BTW.

Before.

After.

 

[DownTheSky]

I can't find that in Google. Can you provide a link?

Edit- Are you referring to Paragon Alignment Tool?

Yes, that's the one. Seen you've ran it already. :thumbsup:

 

[John Connor]

Yeah, thanks for the suggestion. I was waiting for another method and saw that it wouldn't require me to do a Windows repair so I used Paragon instead of the Gparted.

 

[glugglug]

They actually seem pretty disappointing to me, not sure what is wrong...
Here are the AS-SSD results with my Neutron 512GB formatted with 16KB clusters. I tried HDTune a bit as well, but not sure what to include from that, and as far as I can tell it is ignoring the filesystem and going directly to LBAs? Otherwise how does it do thinks like 512 byte random test? ... In which case my cluster size would make no difference.

http://imgur.com/a/ral2u
http://imgur.com/aXkYQFf

Compression bench is separate because imgur got an error on the first upload.

 

[glugglug]

Ran it again with the "high performance" profile in the power control panel. Made a bit of a difference:

http://imgur.com/9lNqq4h

 

[Cerb]

By using 16KB clusters, smaller reads and writes won't exist, in practice. So a 4K file-based test basically becomes a 16KB one. I'm not sure how adjusting the FS to use that as a minimum size would be expected to be beneficial. Those folks making the SSDs know very well that your LBAs are 4K, and the SSDs are made to accommodate that, even when they have larger page sizes.

Sure, WA may take a hit, but keeping decent write cycles while shrinking the NAND didn't come for free to any flash maker. Even with a WA fairly high on average for today, like 5x, though, that's still decades of heavy desktop use, for 3K MLC. If you have <=12KB to write, whether the cluster size is 16K or not isn't going to help. That buffer still needs flushing, and there's no more data to add. What will help is for SSD gen n+1 to offer a write cache that can operate at 4K granularity, so that only well-coalesced writes will typically need to hit the larger-page-size NAND. Caching in a solution to many computer problems, and this just happens to be one of them .

For now, just go back to default 4KB clusters, get that ~100MBps 4K score back, and don't worry about it. Even the new 7% OP Neutrons are pretty speedy, and a bit higher WA won't matter in practice. Back when some drives had 50-150x (see the Patriot Torqx for 150x) WA, it was worth some concern. Now, 10x tends to be on the really high side, outside of write-heavy servers, so a little waste by slightly bigger pages isn't worth losing sleep over.

 

[VirtualLarry]

Even with a WA fairly high on average for today, like 5x, though, that's still decades of heavy desktop use, for 3K MLC.

I just wanted to point out that "3K MLC" was long since past, I think, at 25nm Intel NAND.

Now major flash mfg'rs are down to 18/19/20nm. Surely one would be extremely lucky to even hit 1K P/E cycles. Less for TLC. I don't know if Samsung publishes data, but I think that their TLC drives would be lucky to reach 500 P/E cycles.

And it only gets worse from there.

Eventually, SSDs are going to turn into WORM devices. Except bit longevity won't be all that great either. Maybe a year if you're lucky.

 

[Cerb]

I just wanted to point out that "3K MLC" was long since past, I think

http://www.anandtech.com/show/6884/crucial-micron-m500-review-960gb-480gb-240gb-120gb
http://www.anandtech.com/show/7173/...iew-120gb-250gb-500gb-750gb-1tb-models-tested

It's taken herculean effort, I'm sure, but they've basically maintained endurance over this last shrink.

Eventually, SSDs are going to turn into WORM devices. Except bit longevity won't be all that great either. Maybe a year if you're lucky.

More like they'll be using multiple levels of caching, carefully reading and writing, so as not to damage the memory any more than necessary ("DSP"), and won't be using NAND as we now know it, after a little while (3D NAND appears to be in the pipe, FI). All the big players are working on multiple R&D avenues for the long-term. Like with HDDs, the low-hanging fruit has long been picked.

 

[Binky]

OP, you should put a PSA in your OP - Let the Windows install do the formatting! Don't do it manually.

Forcing a formatted partition (new or existing partition) is not the same as letting windows do everything from a blank (no partitions) drive. Sounds like you got it sorted out.

 

[Gswiss]

Why?



I guess you missed the part about not having to worry about it when installing Windows 7. All you needed to do was a normal install of the OS to the SSD.

There must be a utility available that can do a lossless partition alignment. Good luck.

You can use the free MiniTool Partition Wizard which will correct the alignment on partitions which are not aligned.

 

[glugglug]

By using 16KB clusters, smaller reads and writes won't exist, in practice. So a 4K file-based test basically becomes a 16KB one. I'm not sure how adjusting the FS to use that as a minimum size would be expected to be beneficial.

3 reasons. The first is bolded above. For example, if you have a directory with a thousand files in it, the directory itself is obviously going to be using many clusters (whether they be 4K or 16K). The files weren't all added to the directory instantaneously, so those clusters all got added one at a time, and because of all the files being written getting in the way, those clusters are likely not contiguous. Larger clusters means the directory gets expanded to a new cluster less often.

The second reason is that forcing 16KB clusters (with proper alignment) causes all files to be 16KB aligned. So a 16KB file will always occupy a single page, whereas with 4KB clusters, you have a 75% chance of that file occupying 2 pages (assuming it didn't get fragmented). For a 24KB file, it will always occupy 2 16KB clusters, but there is a 25% chance it would occupy 3 16KB pages on a 4KB cluster filesystem (again even without fragmentation).

The thing is these benefits don't apply to synthetic benchmarks that do only 4KB operations, and more real-world free benchmarks seem hard to find.

The third reason is because TRIM won't always work for the beginning and end of the file with 4KB clusters, because if the TRIM commmand doesn't cover the entirety of the 16KB page, the SSD can't know for certain that you aren't using the other half of the page. It will at least get the middle of a large file; mostly. I was looking at the spec again this weekend curious about the RAID semantics, and saw that the range sent to the TRIM command is specified using a starting LBA and a length. That length is a 16 bit number of 512 byte LBAs, so the maximum block trimmed is 512 bytes * 65536 = 32MB.
Which means that if you TRIM a large file segment that is not page aligned, there will be 1 page every 32MB that doesn't get trimmed because it was only partially covered by any one TRIM operation. 16KB orphaned every 32MB isn't really significant, but it is something..

 

[John Connor]

OP, you should put a PSA in your OP - Let the Windows install do the formatting! Don't do it manually.

Forcing a formatted partition (new or existing partition) is not the same as letting windows do everything from a blank (no partitions) drive. Sounds like you got it sorted out.

I'm not sure I understand. I did let Windows format the drive. I guess where I made my mistake was not deleting the partition first. :\

 

[Cerb]

3 reasons. The first is bolded above. For example, if you have a directory with a thousand files in it, the directory itself is obviously going to be using many clusters (whether they be 4K or 16K). The files weren't all added to the directory instantaneously, so those clusters all got added one at a time, and because of all the files being written getting in the way, those clusters are likely not contiguous. Larger clusters means the directory gets expanded to a new cluster less often.

When the buffers need flushing, they're flushed. When they don't, they aren't. Making the clusters bigger makes everything bigger. It does not change when data gets written, nor how often. When and how often are what determine what you're talking about, except that 16KB clusters mean everything that could be smaller isn't.

Typically, files are not written one little block at a time. They are written as one piece, wherever the FS driver sees fit, whenever possible. Unless your drive remains nearly full, there should be plenty of space with no data "in the way," and the larger you get than 16KB to write, the less that larger size in the NAND will make a difference.

A directory is not a region of the disk. It's a list of pointers. Those pointers can point anywhere else on the disk, and usually do. Windows typically allocates in a very distributed fashion, specifically to leave spare areas of free space, to add other files, and to minimize fragmentation if already-written files are appended to.

The second reason is that forcing 16KB clusters (with proper alignment) causes all files to be 16KB aligned. So a 16KB file will always occupy a single page, whereas with 4KB clusters, you have a 75% chance of that file occupying 2 pages (assuming it didn't get fragmented). For a 24KB file, it will always occupy 2 16KB clusters, but there is a 25% chance it would occupy 3 16KB pages on a 4KB cluster filesystem (again even without fragmentation).

You are assuming that the drive maker has mapped LBAs 16KB, or 4, at a time, aligned. What if they haven't? If not, then it shouldn't be hard to to optimize it so that any >=16KB write gets a page-aligned start. IE, there's no reason a 16KB write starting at sector 363 couldn't be written to a whole page, mapping 363-366 to that page, with no alignment worries whatsoever.

The thing is these benefits don't apply to synthetic benchmarks that do only 4KB operations, and more real-world free benchmarks seem hard to find.

That's because they're hard to make and control, and more useful ones will face licensing limitations.

The third reason is because TRIM won't always work for the beginning and end of the file with 4KB clusters, because if the TRIM commmand doesn't cover the entirety of the 16KB page

TRIM doesn't know or care about pages. It's LBAs. So...

the SSD can't know for certain that you aren't using the other half of the page.

Yes, it can. TRIM gives it precisely that information. LBAs haven't moved up to being 16KB, just because the NAND behind them has moved up to that page size. They're still 4KB or 512b.

 

[Cerb]

I'm not sure I understand. I did let Windows format the drive. I guess where I made my mistake was not deleting the partition first. :\

You want to let Windows write the partition table. Even with HDDs, I like to dd if=/dev/zero of=/dev/sda for a few seconds (I just know I'm going to *facepalm* when we're all moved over to GPT, and the end-drive one gets restored, when I try it ).

 

[glugglug]

ATTO gives me much better results than AS-SSD... wierd how it is so inconsistent from one benchmark to another, and this is on a "balanced" performance profile:
Also, the benchmark gave even better results on the first run. I'm wondering if the drive slows down for a bit after a benchmark run for garbage collection?