SSD Purchase Advice and Inf. on Partitioning It

[Radish]

I've decided to take the plunge and try a SSD - which will be a new experience for me. I'll be installing a Win 7 OS to it and from what reading I've done it seems that the Win 7 installer can natively and automatically manage doing the "alignment" of the SDD correctly - good 'cause I'm not very techy. I've done some basic reading on this and then went to Amazon to see what was on offer. I decided that one of the following 3 SSDs looks like it might be for me (they are all around the 250GB mark in size):

Samsung 850 EVO 250 GB 2.5 inch Solid State Drive

Integral 240 GB V Series V2 Solid State Drive

ADATA SU800 256GB 3D-NAND 200TB TBW Long-Endurance 560MB/s Read and 520MB/s Write High Speed 2.5 Inch SATA III Solid State Drive (ASU800SS-256GT-C)

I'm wondering if anyone could comment on which of these drives looks like it would be the best purchase? My own guess would be that the Adata one looks best but I have never before heard of Adata - so wondering if they are a reliable manufacturer or not.

Also, I am thinking of partitioning the SSD to split the OS partition off from other partitions which I would want to use for portable programs (quite a lot - most of the software I use now is portable editions) and data partitions. I've looked around and it seems opinion is divided on whether or not SSDs should or should not be partitioned. Any comments from experience on this would be appreciated.

Lastly, if I do partition the SSD could someone comment on the following point. My understanding is that to reduce wear for any particular "cell" of an SSD that the SSD will write new data to a less used (or entirely unused) "cell" - in this way, over time, the overall "wear" on "cells" is spread out fairly evenly across the entire SSD. However, if I partition the SSD into multiple partitions does this mean that this cell wear can't be evened out as much as it could be if the entire SSD was just a single partition? I mean, if the SSD was a single partition then it has access to all cells on the SSD to even out wear. But, if the SSD is multiple partitions then does this mean that the SSD can only even out wear by only using the available cells within any given partition? Or does a multiple partition SSD still use all of the SSD to even out cell wear? By that I guess my thinking is that the partitioning of an SSD might be more "virtual" than real. On a HD the partitions are physically discrete parts of the HD. But on an SSD that might not be the case. On an SSD it might be possible to just say "partition" x is just a storage allocation size of, let's say, 50.00GB but that 50.00GB needn't be arranged as 50.00GB of "contiguous cell space" allocated to the "partition" - the cells that constitute that 50.00GB allocation size could (notionally) be anywhere in the matrix of the total number of cells available on the SSD. If that notion of mine is correct then that might mean that even if the SSD is "partitioned" into multiple "partitions" then the SSD still retains the capacity to even out wear by utilising all the available cells on the SSD. (I hope my meaning is making sense here.) If anyone knows which of these methods is used on SSDs for "partitions" and evening out wear I would be grateful for the information.

[Mcinwwl]

Below You'll have a review of ADATA SSD that interests you (512 GB variant, but this shouldn't be much concern). Polish only, but hey, we have translators, and article contains lots of comparison bar charts about speed of different SSDs under different circumstances, that are self-explanatory, I hope.

https://www.purepc.pl/pamieci_masowe/test_dyskow_ssd_adata_ultimate_su800_konkurencja_dla_crucial_mx300

Can't say about partitioning of SSDs, I use my GoodRam Iridium Pro it as a single partition OS drive. Only drawback I can recall is that SSD's tend to slow down when filled up, but I can't find up to date data about this ad-hoc (this article form 2013 might be slightly outdated.

https://www.howtogeek.com/165542/why-solid-state-drives-slow-down-as-you-fill-them-up/

[TELVM]

Windows 7 automatically aligns SSD correctly, no worries there.

I'd go for the 850 EVO 250GB, works like a charm and its 3D TLC is more reliable than the usual planar TLC crap.

You can partition the SSD as you like, no worries. All SSDs come with built-in OP (Over Provisioning) space to ease wear levelling, in the case of the 250GB 850 EVO OP is 9.1% of the 256GB raw NAND capacity (i.e. ~23GB, that's why formatted capacity is only 233GB).

If you're paranoid about longevity, for peace of mind you can leave some space unpartitioned, and it will be automatically used as extra OP space by the SSD internal controller. Not really needed nowadays, unless you task the SSD extremely heavily writing dozens of GBs every day.

You'll love how fast the system runs from an SSD and will never look back.

Edited March 27, 2017 by TELVM

[Radish]

Thanks very much for the responses, much appreciated. EVO it is then, happy that is solved.

On the issue of partitioning and over provisioning I'm a little confused over this. When I partition the SSD I'll just use the sizes I currently have on my HD (with the exception of the last partition which will have to be smaller as the SSD is smaller than my HD). So the partitions on the SSD will all have in excess of 60% free space (with the exception of the last partition).

Now, linking that free space within a partition to the notion of Over Provisioning (OP) is the free space within partitions also used to aid wear levelling? I.e. the free space within partitions is also counted as OP. If that is the case then I don't really need to consider providing unallocated (unpartitioned) free space to help with the longevity of the SSD.

If that isn't the case then would it be better for me to reduce the size of the partitions (so that each partition has less free space) and just used the amount of partition free space "saved" as unallocated (unpartitioned) free space? (I hope this is making sense.)

I guess what I'm getting at is what is the relationship between partition free space, OP and wear levelling?

Lastly, with respect to the boot partition and the page file, how does the page file work on an SSD? I'm thinking that on a HD data written into the page file is always written into a specifically allocated area on the HD. However, as far as my understanding goes, this would be a disaster on an SSD because it means multiple (forced?) writes to the same "cells" on the SSD. So does an SSD manage the page file differently from the way it is managed on a HD? Or maybe I should be asking does Win 7 manage the page file differently on an SSD?

[jaclaz]

You have to understand how the SSD is laid down and interrogated (internally) has very little (or nothing) to do with what the OS sees (or to what the SSD - or hard disk for that matters - internal processor and mappings let the OS see through the data exchange protocol).

Imagine for a moment a SSD (an extremely small one ) with just 16 sectors.

Assume that these sectors are identified by a single hex number, ranging from 0 to F, and let's say that 0 to B are actual storage and that C to F are "overproivisioning".

You are led to believe (because this is what you apparently see through the OS and each and every tool running on the OS) that these sectors are laid down sequentially as follows:
0123456789ABCDEF

but that is ONLY a representation that seems logical and "simple", what you actually know is that, upon interrogation from the OS the device returns those mappings.

So when you create your partitions (let's use 4, 5, 3  sectors ones), you are led to believe that your device layout is:
0123-45678-9AB-(CDEF), i.e.:

First partition: 0123

Second partition: 45678

Third partition: 9AB

Overprovisioning (invisible): (CDEF)

In reality the device is (say) laid down as follows (for *whatever*reason, including easier seeking or queing or thermal considerations, whatever):

0F1E2D3C4B5A6978 <- just an example

so your partitions may be 0F1E-2D3C4-B5A-(6978) or (for all you know) 0F1E(2)-D3C4B(5)-A69(78).

The point is that with any device (including hard disks) manufactured in the last 10-15 years at least there is NO correspondence between the physical layout of the device and its representation to the OS.

jaclaz

 

 

[Radish]

Okay, jaclaz, thank you. Seems like I'll have to completely rethink the way I view HDs though my "suspicions" on how an SSD is managed seem to be in accord with the information you provided.

I'm still though wondering about what is the relationship on an SSD between "free space (notionally shown as being) within a partition", "unallocated space", "over provisioning" and "wear levelling". Is free space within a partition also seen by an SSD as being unallocated space and hence used by the SSD to help with wear levelling? (Rather like if free space in a partition is seen by the SSD as over provisioning space.)

Also how is the page file managed on an SSD? Going by what you are saying my view that there might be multiple forced writes to the same "cells" isn't what happens in practice.

[jaclaz]

Well,you are mixing more things in the same bag.

Let's go back to our 16 sectors device, and simplify the setup with a single partition/filesystem.

You see the mapping as:
0123456789AB(CDEF)

and let us assume that that (by pure chance) does correspond to the real device mapping, i.e.:

0123456789AB=0123456789AB

You write to the device 4 files, each a sector in length, which is symbolized as xywz:

0123456789AB

0123456789AB
xywz----------

The particular file z is often (re-)written, so after a number of rewrite attempts the wear leveling algorithm kicks in and makes the thing:

0123456789AB

012B3456789A

xywz----------

After a huge number of rewrites and after a number of wear leveling sector exchanges, let's say the next is:

0123456789AB

012AB3456789

xywz----------

 one sector (A) goes bad, and is thus removed from the available pool, replaced by C (which is in the overprovisioning area):

0123456789AB

012CB3456789

xywz----------

For all you know (and for what the OS knows), all this time, xywz occupied sectors 0123, while in reality xyw always stayed on the initial sectors 012 BUT z has gone through all the other sectors (exception made for 012) and when a sector eventually died, an overprovisioning area sectors was put in use.

You have to think about two (complex) systems (one is the OS, and the filesystems, and the partitioning, etc. and the other is the device processor and its internal OS) that only talk between themselves through a (standard) protocol that simply does not allow the exchange of detailed information.

When the OS asks for the location of file z, the device replies "Not your business, the file is wherever I see fit, all you need to know is that you can access it by querying for fourth sector, whether what I provide you when you ask for fourth sector is actually the fourth sector of the device or an arbitrary one that I temporary address a "fourth sector" is irrelevant".

As well when the OS asks for a (contiguous) extent on the device (let's say to create in it a partition), the device simply provides a sequence of contiguous addresses (that are internally translated to either contiguous or not contiguous areas).

There is also a difference on the philosophy of the two tasks (wear leveling vs. over provisioning) the wear level algorithms attempt to have at all times all cells/sectors be written (roughly) the same number of times, the overprovisioning only comes into play when an emergence (a cell or sector has gone bad) providing a replacement.

Now imagine a hotel with 16 rooms, with on average 10 of them booked.

The hotel manager will attempt to assign the rooms to customers in such a way that all rooms are used the same number of times in a year, that is wear leveling.

But the (smart) hotel manager will always rent no more than 15 rooms, keeping one free until - say 11:30 PM (i.e. until after most if not all booked guests checked in) -  for emergencies (an appliance breaks, a last-last minute customer, etc.), that is overprovisioning.

When you book the room, you don't actually know which room number you will get, all you know is that you have a room (with given characteristics) booked, and even when you check in, until you are given the room key you don't know which room number the hotel manager will give you, and - even once you are given the key to the room you don't really know for sure if that particular room yesterday had the same room number it would be possible that the (mad) hotel manager every day re-numbers his rooms and re-tags the keys ...

jaclaz

 

[TELVM]

Actually wikipedia has a fairly decent entry on write amplification:

Free user space

The SSD controller will use any free blocks on the SSD for garbage collection and wear leveling. The portion of the user capacity which is free from user data (either already TRIMed or never written in the first place) will look the same as over-provisioning space (until the user saves new data to the SSD). If the user saves data consuming only half of the total user capacity of the drive, the other half of the user capacity will look like additional over-provisioning (as long as the TRIM command is supported in the system).

[Radish]

Thanks again for the responses, things are getting a bit clear now and at least I have a minimal basic understanding of how this SSD thing and its controller function.

Glad to find out that free space of a partition is pretty well seen by the SSD controller as counting towards the over provisioning total. This means I can just set up my partitions as I would normally do on a HD.

Get the SSD tomorrow so looking forward to installing it and Win 7 to it. Hoping the improvement in speed is as much as it is hyped up to be.

Thanks again.

[Mcinwwl]

On 31.03.2017 at 1:15 PM, Radish said:

Also how is the page file managed on an SSD? Going by what you are saying my view that there might be multiple forced writes to the same "cells" isn't what happens in practice.

Works as pagefile on HDD - will write something on the disk, when system or program will decide it's necessary. And, AFAIK, it will be stored on SDD following the same logic, which simplified model was provided by jaclaz, not any sort of special file that tries to wear specific cell of.

So you should be rather concerned by overall data writes along time, not specific files or partitions.

Bigger capacity, improved reliability, and long endurance of 200TB TBW(total bytes written), the drive could be used over 10 years with daily usage of 20GB - taken from the ADATA specs you've linked.

Unless you'll continuously throw thousands of photos, games, movies, databases, (anything that needs lot of storage), you should be fine with the hardware for years. There are, of course, rare occurrences, when specific programs has bad impact on SSD's, but if you'll keep some common sense you shouldn't be struck by sudden loss.

https://www.extremetech.com/computing/239268-spotify-may-killing-ssd

http://www.msfn.org/2016/09/27/adjust-setting-firefox-wears-ssd-drive/

Edited April 1, 2017 by Mcinwwl
Small fix

[Radish]

Thanks very much for the inf. Don't use Spotify so not a concern for me. Do use Firefox. For years I've always set it to write its "Cache2" data into a ramdisk - that can literally be several thousands of small files on a daily basis. Likewise I always launch Firefox via a batch file that forces it to write any data it would normally write to TEMP and TMP folders (on the SSD/HD) into the ramdisk.

Instructions to write Cache2 to ramdisk (where ramdisk is drive letter W:):
Go about:config and search for the entry browser.cache.disk.parent_directory (if setting does not exist then create it as a new 'string') then enter the path where Firefox will create the cache folder W:\\ FIREFOX\\ (needs double back-slash not single).

It is possible via Firefox config settings to write the cache stuff into memory anyway (thus by-passing the need for a ramdisk) but my tests for that method showed that if doing it that way it still writes a small amount of stuff to the HD - so I prefer to use a ramdisk. This page explains how to do this: https://thetechjournal.com/how-to/tutorial-how-to-move-your-mozilla-firefox-cache-memory.xhtml

The batch for forcing Firefox temp/tmp files to ramdisk (I use this launch method for several programs, works well):

set TEMP=W:\TEMP
set TMP=W:\TMP
start "" "C:\Program Files (x86)\INTERNET\FIREFOX\firefox.exe"
exit

To get a really good freeware ramdisk: http://www.majorgeeks.com/files/details/softperfect_ram_disk.html

I did look at the article your second link points to which was interesting as I didn't know of that setting in Firefox. I later found out it might be possible to completely turn off this "session restore" feature of Firefox. Details here: http://portableapps.com/support/firefox_portable#performance

Thanks again. I can see now that setting up this SSD is going to take me a couple of days with tweaking and recording what I did. Ah, well...

[TELVM]

I went a step beyond and have been installing the whole browser (Pale Moon portable) on ramdisk for years. Lightning quick browser experience.

If it isn't already, don't forget to enable AHCI before installing or cloning system to SSD.

[jaclaz]

11 hours ago, Mcinwwl said:

Unless you'll throw thousands of photos, games, movies, databases, (anything that needs lot of storage), you should be fine with the hardware for years.

To be picky (as I am) not exactly, if you do not throw thousands of photos, games, etc., you can buy a smaller SSD, the problem does not arise when you throw a lot of data on the SSD (that's the actual reason why it is made), it is when you continuously overwrite those data.

Even in this case, modern SSD's have a life that will in most cases will largely exceed the life of the PC

http://techreport.com/review/24841/introducing-the-ssd-endurance-experiment

http://techreport.com/review/27909/the-ssd-endurance-experiment-theyre-all-dead

jaclaz

 

[Radish]

20 minutes ago, TELVM said:

I went a step beyond and have been installing the whole browser (Pale Moon portable) on ramdisk for years. Lightning quick browser experience.

Might try something like that in the future, just for the fun.

ACHI I already checked BIOS yesterday - all fine. Thanks for the mention though.

[Mcinwwl]

4 hours ago, jaclaz said:

To be picky (as I am) not exactly, if you do not throw thousands of photos, games, etc., you can buy a smaller SSD, the problem does not arise when you throw a lot of data on the SSD (that's the actual reason why it is made), it is when you continuously overwrite those data.

Truly, thanks for pointing this out. I did a small correction to the post, should be a bit better right now. I originally thought about games, cos the new ones can download a gigabytes worth with small gap between each update (Quantum Break for Xbox One had an update that was bigger than original game - which meant redownloading all audio, textures, videos etc. plus a small fix, over 60 GB. And yeah, I know we are talking about Windows PC, but Xbox can have SSD, too. And since Windows 10 offer cross-play with Xbox One with UWP-packed games from windows store, this is worth remembering. And we need to remember, that little publishers care about publishing their games polished, so this might become standard... ok, enough :>).