Partitioning a SSD

[pcslookout]

Is it ok to partition a big SSD or not recommended ?

The reason is so I can have my OS and Applications on a smaller 30 to 50 GB partition and the left over space for games. So when I go to make a image I only have to backup the OS and Applications partition which will have a lot less used space. Where games are normally 30 to 50GB alone.

 

[poohbear]

I recall reading it's not recommended, but that was years ago. At any rate, it's kinda pointless to create partitions with SSDs. HDDs might benefit from partitions because it's faster to defragment them, but u never defragment a SSD, so what's the point exactly? Just make a seperate directory & let Windows take care of the rest.

 

[corkyg]

It's not a problem. Have partitioned my OS drive for years. I have a small partition for my page file. It isn't necessary, but I like it that way. And, there is also an OEM Recovery partition that is somewhat hidden. As far as programs, apps, and data go, I keep them on their own SSD or HDD, depending on the machine.

 

[Coup27]

I recall reading it's not recommended, but that was years ago. At any rate, it's kinda pointless to create partitions with SSDs. HDDs might benefit from partitions because it's faster to defragment them, but u never defragment a SSD, so what's the point exactly? Just make a seperate directory & let Windows take care of the rest.

There is no technical reason why you cannot partition an SSD. Whether there is any point comes down to the useage case, which if you had read the OP you would have seen that there is a benefit to the user to use partitions.

 

[Ketchup]

Another agreement. Nothing wrong with doing it, but no real reason to.

 

[Sheep221]

I recall reading it's not recommended, but that was years ago. At any rate, it's kinda pointless to create partitions with SSDs. HDDs might benefit from partitions because it's faster to defragment them, but u never defragment a SSD, so what's the point exactly? Just make a seperate directory & let Windows take care of the rest.

Partitioning magnetic HDD definitely does NOT speed up the defragmentation.

 

[Ketchup]

Partitioning magnetic HDD definitely does NOT speed up the defragmentation.

Sure it does. Less space for fragments to move to = fewer files that would be fragmented. Why do you think it wouldn't?

 

[Sheep221]

Sure it does. Less space for fragments to move to = fewer files that would be fragmented. Why do you think it wouldn't?

Fragmentation is physical process, when you set up your partitions you just created higher level folders in file system table but not much more. When you have fragmented drive, fragments of file from one partition can be found around fragments of files from other partition. In this sense partitions would have to be physically bound to specific platter or part of that platter with fixed not adjustable size and would likely be included in new HDD. It may speed up defragmentation because maybe OS handling the defragmentation program might execute some of its algorithms more efficiently, but it would only speed up the process by few minutes at best. Although my main rig is now entirely with SSD storage I used to have drives with varying amount of partitions and solo partitions and didn't really ever notice any speed improvement in this regard. Modern drives are faster that's why they also defragment faster, but not much more than that.

 

[VirtualLarry]

In this sense partitions would have to be physically bound to specific platter or part of that platter with fixed not adjustable size

Uhh, that's what partitions are for HDDs. Physical "chunks" of the drive.

 

[VirtualLarry]

when you set up your partitions you just created higher level folders in file system table but not much more

This is incorrect as well. Partitions are lower-level than Filesystems, Filesystems exist WITHIN partitions. Partitions are NOT a "higher-level entry in a Filesystem".

(Edit: At least in the context of an IBM-compatible PC. Unix/ZFS/etc. may be a little different.)

 

[Ketchup]

Fragmentation is physical process, when you set up your partitions you just created higher level folders in file system table but not much more. When you have fragmented drive, fragments of file from one partition can be found around fragments of files from other partition. In this sense partitions would have to be physically bound to specific platter or part of that platter with fixed not adjustable size and would likely be included in new HDD. It may speed up defragmentation because maybe OS handling the defragmentation program might execute some of its algorithms more efficiently, but it would only speed up the process by few minutes at best. Although my main rig is now entirely with SSD storage I used to have drives with varying amount of partitions and solo partitions and didn't really ever notice any speed improvement in this regard. Modern drives are faster that's why they also defragment faster, but not much more than that.

We are going a bit OT, so I am just going to encouage you to do some research on how partitions work, because either you have been supplied with misinformation, or you are just guessing and have no idea.

Bringing it back home, fragmenation is not a problem on SSDs since the data is placed in optimal locations from the start, which also removes one of the big reasons for creating separate partitions on these drives.

 

[poohbear]

Fragmentation is physical process, when you set up your partitions you just created higher level folders in file system table but not much more. When you have fragmented drive, fragments of file from one partition can be found around fragments of files from other partition. In this sense partitions would have to be physically bound to specific platter or part of that platter with fixed not adjustable size and would likely be included in new HDD. It may speed up defragmentation because maybe OS handling the defragmentation program might execute some of its algorithms more efficiently, but it would only speed up the process by few minutes at best. Although my main rig is now entirely with SSD storage I used to have drives with varying amount of partitions and solo partitions and didn't really ever notice any speed improvement in this regard. Modern drives are faster that's why they also defragment faster, but not much more than that.

a 100gb partition is gonna be faster to defragment than a 1tb partition, u can blame it on the OS or whatever, but the point still stands. no need to be pedantic.

anyways if OP is doing it to make it simpler to image the partition, then all the power to him as it won't affect the SSD negatively.

 

[KingFatty]

Point of clarification request: if you have a partition for OS+system, and a partition for games+apps, what would happen if you only back up the OS+system partition and then restore it?

Won't that partition try to refer back to all the missing games+apps and so be kinda messed up? I just think it would be nice if your backup was restored and it just worked nicely, without being all broken, or maybe I'm missing something?

How is the OS-only partition helpful for backups?

 

[Essence_of_War]

when you set up your partitions you just created higher level folders in file system table but not much more.

This is incorrect. Partitioning a disk creates entries in the MBR/GPT partition table. It carves volumes out of the physical disk, and you can actually have different filesystems living on each of your disk partitions. The key point here is that the partition table lives at the beginning of a disk where there is no filesystem.

When you have fragmented drive, fragments of file from one partition can be found around fragments of files from other partition.

This is not at all what people mean when they talk about fragmentation.

 

[Essence_of_War]

Point of clarification request: if you have a partition for OS+system, and a partition for games+apps, what would happen if you only back up the OS+system partition and then restore it?

Won't that partition try to refer back to all the missing games+apps and so be kinda messed up? I just think it would be nice if your backup was restored and it just worked nicely, without being all broken, or maybe I'm missing something?

How is the OS-only partition helpful for backups?

90% of my games are from Steam. 5% are from blizzard. 5% are other.

Steam and modern blizzard games don't need to be "installed" in the sense of like storing some important game key in the registry. You can just point the battlenet client or the steam client at your starcraft2, or steamapps/common directory and you're good to go.

Games are big. OS and most other applications are fairly small. Imaging the OS/applications partition is relatively fast, and the images don't take up much space. You can then do simple drag-drop type backups of the steamapps etc. I use rsync to back up my windows games volume, for example. Very fast, very efficient.

 

[Elixer]

Is it ok to partition a big SSD or not recommended ?

The reason is so I can have my OS and Applications on a smaller 30 to 50 GB partition and the left over space for games. So when I go to make a image I only have to backup the OS and Applications partition which will have a lot less used space. Where games are normally 30 to 50GB alone.

Yes, as was said, it is fine to partition a big SSD.
I rather prefer to have a specific OS partition, so, in case I want to clean install again, it would be simple.

 

[BSim500]

Partitioning magnetic HDD definitely does NOT speed up the defragmentation.

As others have said not only does it speed it up, it can significantly reduce it in the first place. Eg, download a large multi-GB file and/or recording a DVB stream off a TV tuner whilst simultaneously browsing the web and that large file will often be heavily fragmented in the hundreds / thousands due to Windows intermittently writing lots of tiny browser cache files in between which will split up that large file (even if you have a lot of free space). See this yourself by downloading Defraggler which shows exactly how many fragments files are split up in. Now create a small "cr*p" partition just for the web cache, temp files (and any other app which writes lots of small files), or even use a RAM drive, and that single large file will barely be fragmented at all if nothing else is written / running in the background. If the "threshold" for a smart defragmenter is say "skip over files with fewer than 6-10 fragments", then a file with 2-5 fragments vs 5,000, may mean not even needing to defrag it at all.

Of course that's for HDD's. For SSD's everything is "flat" due to the FTL (Flash Translation Layer) and partitions no longer have dedicated assigned cells as HDD's do partitioned sectors, so it doesn't work as above. However, a lot of people still partition for convenience and as OP said, it's useful to just have a small Windows partition separate from "portable" game / data files that eliminates the need to reinstall everything if you have to reinstall Windows (or just massively reduces the size of a Windows image). In short, yes it's perfectly fine to partition an SSD.

Point of clarification request: if you have a partition for OS+system, and a partition for games+apps, what would happen if you only back up the OS+system partition and then restore it? Won't that partition try to refer back to all the missing games+apps and so be kinda messed up?

Depends on the app / game. Applications like Office generally need reinstalling. However, as Essence of War said, many Steam games are "portable" as are many GOG and older retail disc games that store settings locally in .ini files vs the registry. Time saved = not just reinstall time, but getting each game set up as you want it (key bindings, settings, etc). One exception is Steam's "CEG" DRM (Custom Executable Generation). This is where the .exe is locked to your hardware, so if the reason for reinstalling Windows is a mboard upgrade, you'll probably need to reinstall those games again as you'll need a new .exe anyway. Some games may be broken, but in general many are in fact quite "portable" between Windows installs.

 

[Sheep221]

Ofc defragmenting is faster for a partition you don't do any writes on at all, but what was the point of creating it in the first place, to just leave it there for nothing? If you have system partition and data partition(programs, user data, media, downloads) and you use your computer daily for many sorts of things both of your partitions will be fragmented one way or another, as I said it may speed up the process by some margin but not much. If you have fragmented 1 TB partition, I don't see what is difference between 2 fragmented 500 GB partitions, or arguing that data partition is less likely to contain many smaller files, some programs - editors of any kind contain hundreds of thousands of small program files.
I know that wikipedia is not very reliable to use it as reference but hey, shall we?

A common strategy to optimize defragmentation and to reduce the impact of fragmentation is to partition the hard disk(s) in a way that separates partitions of the file system that experience many more reads than writes from the more volatile zones where files are created and deleted frequently. The directories that contain the users' profiles are modified constantly (especially with the Temp directory and web browser cache creating thousands of files that are deleted in a few days). If files from user profiles are held on a dedicated partition (as is commonly done on UNIX recommended files systems, where it is typically stored in the /var partition), the defragmenter runs better since it does not need to deal with all the static files from other directories. For partitions with relatively little write activity, defragmentation time greatly improves after the first defragmentation, since the defragmenter will need to defragment only a small number of new files in the future.

None of this voids my post in the sense of speed - you browse web a lot, you download a lot, you work with files a lot, you install programs a lot you will fragment your disk heavily and will need long time do defragment it, if you use your computer to read mail once a week you will fragment it much less, but none of this has to do anything with partitions, I don't deny that partition may speed up defragmentation in certain usage scenarios but definitely not universally.
Scenario where you have files from one partition fragmented over other partition does happen as well, if you do delete partitions on fragmented hard disk and create new ones with different sizes you created just this, the next time you defragment your hard disk, the defragmenter has to rearrange fragments also of those deleted files - rendering them impossible to recover.

 

[BSim500]

Ofc defragmenting is faster for a partition you don't do any writes on at all, but what was the point of creating it in the first place, to just leave it there for nothing?

^ Not what I said. "The point" of creating it in the first place for most people is organization (as several people have explained to you above...) For some it means not needing to reinstall hundreds of games with a Windows reinstall, or that the "partition snapshot" backup is only 30-50GB and a few minutes instead of Terabytes and hours. For others it means less visual clutter in Explorer in having only data subfolders on one drive without all the C: system subfolders. Or setting up automated full drive backups of a data partition is easier without having to manually add a load of exclusions. Everyone has their own organizational quirks.

Slowing down fragmentation on HDD's (no one said anything about eliminating it completely) is simply a side effect under some usage scenarios. The example I gave earlier is exactly what I've witnessed in person on my HTPC - a 90% reduction in fragmentation of newly created large media files when all the temporary clutter that typically gets written simultaneously (browser cache especially) is on another partition / disk / RAMDisk. Wikipedia can keep its theories, and I'll keep my observations.

 

[VirtualLarry]

Scenario where you have files from one partition fragmented over other partition does happen as well, if you do delete partitions on fragmented hard disk and create new ones with different sizes you created just this, the next time you defragment your hard disk, the defragmenter has to rearrange fragments also of those deleted files - rendering them impossible to recover.

WUT? Talk about moving the goalposts. You are saying, you create partitions, format them, use them for storing files, they get fragmented. Then you delete those partitions, create new partitions of different sizes, and then write to them, and then those original partitions are unrecoverable? Any writing done to a drive, may make forensic file recovery more difficult or impossible. Regardless of partition re-writing or defragmenting.

That doesn't back up your statement about files being fragmented across partitions / filesystems at all.

Edit: You need to educate yourself on how partitions and filesystems work.

 

[hojnikb]

I recall reading it's not recommended, but that was years ago. At any rate, it's kinda pointless to create partitions with SSDs. HDDs might benefit from partitions because it's faster to defragment them, but u never defragment a SSD, so what's the point exactly? Just make a seperate directory & let Windows take care of the rest.

i dont think it was ever not recommended. Maybe by people, that dont understand wear leveling.

 

[BonzaiDuck]

I see two issues: whether it's a good idea to partition an SSD or otherwise create multiple logical volumes on it; and file organization and registry dependence.

Everybody has answered the question about partition and volumes. There's nothing wrong with doing that.

We usually try and separate OS with programs from data files. It perhaps makes backup easier both ways.

In my case, though, because games take up a lot of storage, I created "Program Files" and "Program Files (x86)" directories on another drive -- an HDD. I still back up both the boot-system drive and this second drive with a single operation nightly to my server. So I can recover the HDD for instance separately and restore it. Thus it no longer presents a problem for me. These backups to the server for four workstations consume maybe 600GB of space on the server out of 8TB.

How I deem it viable to use an HDD, I've explained in other posts and threads. But essentially, in benchmarks, my "HDD" shows a 4K random-write speed of ~300MB/s connected to an SATA2 port, and a 4K random-read rate of around 580MB/s.

Still, an interesting question. What are you going to do with a 1TB SSD, if the OS and programs only consume, say, 300 GB? Personally, I'd probably create two logical volumes on a 1TB SSD, just as the OP contemplates.

If it weren't for my server backup, I'd have to resolve the problem of taking local backups, and I suppose I'd get a hot-swap bay and caddy with a 1TB HDD to back up the SSD.

 

[pcslookout]

I found this which was a interesting read.

http://superuser.com/questions/808833/disadvantages-of-partitioning-an-ssd

 

[Elixer]

I found this which was a interesting read.

http://superuser.com/questions/808833/disadvantages-of-partitioning-an-ssd

I would rate that answer with a 2 out of 10, it isn't very accurate.

SSDs themselves don't work on a partition level, they work on a block/page level.
They don't care what data is being stored, unless it is to compress said data to make it more efficient (like what SandForce controllers did).
The filesystem is the beast that cares about partitions and the like.

What all this boils down to is, OS request goes to the filesystem. The filesystem looks at its file table, and tells the SSD to get LBA 520 (for example). The SSD then looks at its table, and says, LBA 520 is pointing to block/page 3928, and it retrieves that.
The next time something writes to block/page 3928, the SSD can move that data to another block, and it keeps track of that.
So, the next time around the OS asks for the same file, it again says LBA 520 please, the SSD looks at the lookup table and says sure, here is block/page 1200. It is the same data as before, but the SSD has internally moved that data around.
There are a ton of things that SSDs do behind the scenes, so, you never actually know what block/page the data is actually on via OS calls.

Wear leveling won't have as much free space to play with, because write operations will be spread across a smaller space , so you "could", but not necessarily will wear out that part of the drive faster than you would if the whole drive was a single partition unless you will be performing equivalent wear on the additional partitions (eg: a dual boot).

No, as long as the SSD has X% free space in total, then all is fine.
Write operations happen on a block/page size, there is no "smaller space" here. You can't "wear out" one partition over the other, it doesn't work that way! (Though, look up the 840EVO fix to see a firmware bug)

Like hard drives nand-flash S.S.D's are sequential access so any data you write/read from the additional partitions will be farther away than it "might" have been if it were written in a single partition, because people usually leave free space in their partitions. This will increase access times for the data that is stored on the additional partitions.

False again, he is thinking filesystem level, NOT block/page level. At any time the SSD can map something that resides in the "first partition" to *any place* that the SSD finds an optimal location for that data. It could be anyplace on the SSD, in any NAND chip. It just depends.

Less total space increases the likely hood of writing fragmented files, and while the performance impact is small keep in mind that it's generally considered a bad idea to defragement a nand-flash S.S.D. because it will wear down the drive. Of course depending on what filesystem you are using some result in extremely low amounts of fragmentation , because they are designed to write files as a whole whenever possible rather than dump it all over the place to create faster write speeds.

A SSD's idea of fragementation is MUCH different than the filesystem's view of fragmentation.
Again, to the *filesystem*, it might seem like the data is all over the place in the partition. However, to the SSD, that data could be in sequential blocks/pages, or, anyplace. The reverse is also true, to the *filesystem* said file might show 0% fragmentation, but on the SSD, it could be anywhere, in multiple different pages. There is no 1:1 correlation between SSD mapping and filesystem mapping.

Personally, I still think it is optimal to have a dedicated OS partition that you can clean install anytime you want.

 

[BSim500]

I found this which was a interesting read.

http://superuser.com/questions/808833/disadvantages-of-partitioning-an-ssd

^ As Elixer said, the answer is incorrect (and needs voting down). When you partition a HDD, you're assigning contents of partitions to physical sectors. If you partition it into C & D, then each will only be written to its assigned sectors. If you do 1,000x writes on one and only 1x on the other, then half the disc will see 1,000x writes and the only half only 1x. The OS "directly sees" where it's writing, so to speak.

But SSD's store everything "flat" with an intermediate Flash Translation Layer merely giving the illusion of "sectors". You could halve an SSD into C & D, and both can be written anywhere in the flash cells. What Windows "sees" is rarely where stuff gets written. If you partition an SSD in half and do 1,000x writes in one partition but only 1x write in the other, you won't end up with half the cells being written 1,000x times and the other half almost unused as the SSD's wear levelling operates at a lower level than partitions. "Block level" stuff doesn't even 'see' partitions as the OS does. Elixir is also correct that the "image map" shown on many defragmenters doesn't match up with how data is actually stored.