I strongly recommend you to do the partitioning. It makes sense.
Advantages
- Formatting Convenience - If you ever need to format, you do not have to copy your data out first since it resides on another partition. You can just format the OS partition.
- Increased Security - There is increased data security, since your data is now on another partition. Malware that affects or scan files on only one single drive will not scan your data partition.
- Improved Performance - you can defragment your OS drive for max performance, and not worry about it being fragmented so fast, since data (where it changes the most), resides on another partition.
Disadvantages
- Slower Data Moves - Moving data from one partition to another takes awhile, unlike moves in the same partition.
- Set-up Inconvenience - There are advisable steps to do in order to let your OS use the other partition as data effectively without impacting your workflow. e.g Moving your My Documents folder to the other partition.
- Reduced Space - When you have 2 partitions, some space is lost.
That said, you definitely should partition. In fact, I recommend THREE partitions. OS, DATA, CACHE. Been following this style for years, and never regretted.
Partitioning is only ever presented as a logical assignment of space... It's not really a physical operation on modern spinning disks either.
Take sector reassignments as an example - you have no control over where data is physically stored.
With solid-state storage like SSDs and SD cards, this concept is taken to the next level, with logical blocks assigned to physical storage in a way that is completely out of the control of the user and even Operating System - the main reason for this being wear levelling. In addition to this, a growing number of SSDs will encrypt their entire contents, so the data isn't accessible to you at a physical level anyway.
If I partition a SSD, will it really partition the drive physically
No, but it never was a physical operation anyway.
... or will the SSD Controller (for example Samsung Phoenix) fool the OS that it is partitioned but it actually manages the drive by itself?
Partition tables are typically something that the storage device knows nothing about - it presents itself to the operating system as "a massive array of blocks" (hence the term "block device").
It is entirely the Operating System's job to correctly interpret the partition table, and present the logical partitions for use (e.g: as the space to store a filesystem). This presentation is not much more than simply "from x to y is referred to as partition 1" - it's a transparent window that bounds your access to the underlying storage device, and restricts access to between these points.
In the (very rough) example above, we have:
- The partition table at the front, in purple. As mentioned above, it informs the OS where the partitions logically are in the storage device.
- Partition #1 starts at location 8, and runs through to location 456 (i.e: it's 449 units in size).
- Unused space
- Partition #2 starts at location 504, and runs through to location 904 (i.e: it's 401 units in size).
- Unused space
In this example, the OS will present the two as things that can be used... you'll probably have filesystems on both, and the contents of the filesystem will be presented at a mountpoint (like C:\
on Windows, or perhaps /home
on *nix).
The "foolery" that you're referring to is actually lower than this... The SSD keeps a map of where each logical block is physically located. But this is completely invisible to everything outside of the SSD. If you looked at the raw / physical flash, then it would be:
- A jumble of non-sensical mess that you'd need to reconstruct (using the SSD's propietary map)
- More and more likely it would appear as random noise, with no data or patterns present, because it's encrypted.
To clarify a potential source of confusion, some things (like eMMC storage) do support physical partitioning, but this is not what you're referring to.
For eMMC, it's a one-time operation that can be used to physically keep one region of flash separate from another - the wear levelling algorithms will never cross that boundary. It can also be used to treat a section as SLC rather than MLC, supposedly for greater longevity and reliability, and is intended specifically for embedded systems.
Best Answer
SSDs do not, I repeat, do NOT work at the filesystem level!
There is no 1:1 correlation between how the filesystem sees things and how the SSD sees things.
Feel free to partition the SSD any way you want (assuming each partition is correctly aligned, and a modern OS will handle all this for you); it will NOT hurt anything, it will NOT adversely affect the access times or anything else, and don't worry about doing a ton of writes to the SSD either. They have them so you can write 50 GB of data a day, and it will last 10 years.
Responding to Robin Hood's answer,
That is totally wrong. It is impossible to wear out a partition because you read/write to only that partition. This is NOT even remotely how SSDs work.
An SSD works at a much lower level access than what the filesystem sees; an SSD works with blocks and pages.
In this case, what actually happens is, even if you are writing a ton of data in a specific partition, the filesystem is constrained by the partition, BUT, the SSD is not. The more writes the SSD gets, the more blocks/pages the SSD will be swapping out in order to do wear leveling. It couldn't care less how the filesystem sees things! That means, at one time, the data might reside in a specific page on the SSD, but, another time, it can and will be different. The SSD will keep track of where the data gets shuffled off to, and the filesystem will have no clue where on the SSD the data actually are.
To make this even easier: say you write a file on partition 1. The OS tells the filesystem about the storage needs, and the filesystem allocates the "sectors", and then tells the SSD it needs X amount of space. The filesystem sees the file at a Logical Block Address (LBA) of 123 (for example). The SSD makes a note that LBA 123 is using block/page #500 (for example). So, every time the OS needs this specific file, the SSD will have a pointer to the exact page it is using. Now, if we keep writing to the SSD, wear leveling kicks in, and says block/page #500, we can better optimize you at block/page #2300. Now, when the OS requests that same file, and the filesystem asks for LBA 123 again, THIS time, the SSD will return block/page #2300, and NOT #500.
No, this is again wrong! Robin Hood is thinking things out in terms of the filesystem, instead of thinking like how exactly a SSD works. Again, there is no way for the filesystem to know how the SSD stores the data. There is no "farther away" here; that is only in the eyes of the filesystem, NOT the actual way a SSD stores information. It is possible for the SSD to have the data spread out in different NAND chips, and the user will not notice any increase in access times. Heck, due to the parallel nature of the NAND, it could even end up being faster than before, but we are talking nanoseconds here; blink and you missed it.
Nope, sorry; again this is wrong. The filesystem's view of files and the SSD's view of those same files are not even remotely close. The filesystem might see the file as fragmented in the worst case possible, BUT, the SSD view of the same data is almost always optimized.
Thus, a defragmentation program would look at those LBAs and say, this file must really be fragmented! But, since it has no clue as to the internals of the SSD, it is 100% wrong. THAT is the reason a defrag program will not work on SSDs, and yes, a defrag program also causes unnecessary writes, as was mentioned.
The article series Coding for SSDs is a good overview of what is going on if you want to be more technical about how SSDs work.
For some more "light" reading on how FTL (Flash Translation Layer) actually works, I also suggest you read Critical Role of Firmware and Flash Translation Layers in Solid State Drive Design (PDF) from the Flash Memory Summit site.
They also have lots of other papers available, such as:
Another paper on how this works: Flash Memory Overview (PDF). See the section "Writing Data" (pages 26-27).
If video is more your thing, see An efficient page-level FTL to optimize address translation in flash memory and related slides.