SSD partitioning
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.
On an SSD there is no fixed assignment which chip contains which sector. Therefore the "partitioning" is not existing on hardware level (because the SSD controller dynamically assigns the flash chip sections to sectors to perform wear leveling and increase the life of the SSD).
If you name this "fooling" than yes. But you will only recognize this if you solder out the flash chips and access them directly. Or if you manage to access the SSD bypassing the SSD controller (normally this is not possible).
However in the data level the partitioning is existent and visible to the OS and that is everything what matters.