• Welcome to TechPowerUp Forums, Guest! Please check out our forum guidelines for info related to our community.

Are there wear problems from partitioning a SSD?

My way of politely questioning birdie
He was saying that Defrag utility in Windows runs TRIM on a SSD, right?
 
Over provisioning leaves some free space
Because data is spread evenly over the SSD, if you leave 10% of the SSD unpartitioned every single memory chip has 10% free (This is an oversimplification, but its close enough - with proprietary tech and firmwares etc we'll never know for sure)
That helps them out, since they can spread the wear a little more evenly
That's wear leveling, and your're right, it's probably a bit less efficient when the drive is close to full.

However, there's write amplification to consider, too. The controller keeps track of everything - partially written blocks, empty blocks, blocks that can be erased. When it receives data to be written, it can better optimise writes if it has a large enough stock of blocks in a suitable state. If that's not the case then it must sometimes do the most damaging thing - erase blocks that are still mostly empty, which leads to high WA.
(A page is 4-16 KB, which is the minimum unit that can be written; and a block, also called an "erase block", is between 1-8 MB or so and is the minimum unit that can be erased).

The worst thing that can happen is an almost full drive will have to spread files over everything - you could write 100MB, but that could require filling and erasing every single flash module. Like how a single 1KB file can take 4KB of space, if you had to split 100MB over the final 500MB of your SSD, you would use a LOT more writes than on an empty drive
There would still be 100 MB of writes but there would be potentially 500 MB of blocks to erase beforehand - a case of a very high WA.
(It's the whole layers shenanigans - a drive with 192 layers requires all 192 layers to get wiped and re-written for even 1KB of new data to be written)
The controller can, and does, add data to a partially written block, so this can't be true in all cases. The thing I don't understand well is, when is this possible and when it isn't.
As for the defragging of an SSD:
Oh god i hope you were joking
Windows, even #11, does sometimes defragment an SSD. But I'm sure it's done very conservatively, with smallest amount of writes possible. If a file, for example one of Windows registry files, is horribly fragmented - I mean, tens of thousands of fragments - it still makes sense to reduce that. Not to perfection but maybe to a couple hundred fragments. It should make file access less random and more sequential and save users from testing the lower limit of random read/write IOPS every day.

Edit: Classic tools such as Windows 98 defragmenter and Norton Speed Disk remain useful too. Is there a greater satisfaction than watching the construction of a mandala wall of ordered colourful bricks where there was chaos before? And it can't cost more than 50¢ (per show) when an entire QLC SSD is about $70/TB.
 
Last edited:
He was saying that Defrag utility in Windows runs TRIM on a SSD, right?
Defrag on an SSD either TRIMs, or is a no-op. Given how smart current SSD controllers are, even the first is likely a no-op because the controller likely treats commands like TRIM that can affect block allocation, and therefore performance, as hints rather than pure "do this now" orders - the controller automatically runs TRIM itself at quiet times when the drive is at low load anyway.

Windows, even #11, does sometimes defragment an SSD. But I'm sure it's done very conservatively, with smallest amount of writes possible. If a file, for example one of Windows registry files, is horribly fragmented - I mean, tens of thousands of fragments - it still makes sense to reduce that. Not to perfection but maybe to a couple hundred fragments. It should make file access less random and more sequential and save users from testing the lower limit of random read/write IOPS every day.
Uh, no. Completely, utterly, horribly wrong. As has already been explained multiple times in this thread, the operating system doesn't know that files on an SSD are fragmented or not because the SSD controller handles file allocation itself internally and does not need to expose that information externally.
 
Why does a hard drive slow up when near full if it can just wait till things are quiet?
 
Last edited:
Why does a hard drive slow up when near full if it can just wait till things are quiet?
Are you asking "why don't hard drives automatically defragment themselves"?

* hard drives never have a quiet time; they're so slow that they're always busy
* hard drive defragmentation is an extremely performance-intensive process that makes the drive's terrible performance far far worse, so it cannot happen at a quiet time because as per the previous point, there is no quiet time!
* hard drives were created in a time before multi-gigabyte files and the need to prevent said files from becoming fragmented
* hard drive defragmentation was thus invented by operating systems to overcome file fragmentation issues, not by hard drive manufacturers (who treated it as something that's not their problem)
 
For future reference, SSD's gain nothing but extra sector wear from defragmentation. Hard Drives yes, there are serious benefits. Solid State Drives, no.

Defrag on an SSD either TRIMs, or is a no-op. Given how smart current SSD controllers are, even the first is likely a no-op because the controller likely treats commands like TRIM that can affect block allocation, and therefore performance, as hints rather than pure "do this now" orders - the controller automatically runs TRIM itself at quiet times when the drive is at low load anyway.


Uh, no. Completely, utterly, horribly wrong. As has already been explained multiple times in this thread, the operating system doesn't know that files on an SSD are fragmented or not because the SSD controller handles file allocation itself internally and does not need to expose that information externally.

Storage Optimizer will defrag an SSD once a month if volume snapshots are enabled. This is by design and necessary due to slow volsnap copy on write performance on fragmented SSD volumes. It’s also somewhat of a misconception that fragmentation is not a problem on SSDs. If an SSD gets too fragmented you can hit maximum file fragmentation (when the metadata can’t represent any more file fragments) which will result in errors when you try to write/extend a file. Furthermore, more file fragments means more metadata to process while reading/writing a file, which can lead to slower performance.

When he says volume snapshots or "volsnap" he means the Volume Shadow Copy system in Windows. This is used and enabled by Windows System Restore when it takes a snapshot of your system and saves it so you can rollback to a previous system state. I used this just yesterday when I install a bad driver. A bit of advanced info here - Defrag will only run on your SSD if volsnap is turned on, and volsnap is turned on by System Restore as one needs the other. You could turn off System Restore if you want, but that turns off a pretty important safety net for Windows.

@Wirko is correct.
 
Last edited:
Why does a hard drive slow up when near full if it can just wait till things are quiet?
Do you mean hard drives or SSDs? For HDDs it's due to not having enough sequential free area on the disk to write to, forcing it into extremely slow random writes. For an SSD, it's due to not having evough free space to achieve a high level of parallelism, as well as having to erase and re-write blocks rather than just write to empty or partially empty ones.
 
Are you asking "why don't hard drives automatically defragment themselves"?

My bad... force of habit... I meant

Why does a solid state hard drive slow up when near full if it can just wait till things are quiet?
 
And ummm... SSD's are fast because when they read, the data comes in from multiple chips at once like in a RAID 0 array - defragging puts them together, which would burn out the drive to slow it down. Why?
This doesn't happen.
The defrag utility doesn't rearrange actual blocks on the SSD, it rearranges the fragments of the virtual layout of the filesystem that is provided by the SSD's controller to fool the OS.

Writes and reads still occur needlessly, but they are still performed on multiple chips, transparently handled by the controller.
 
the controller likely treats commands like TRIM that can affect block allocation, and therefore performance, as hints rather than pure "do this now" orders - the controller automatically runs TRIM itself at quiet times when the drive is at low load anyway.
Yes, those are just hints. Pretty much necessary hints because without them, the controller would have no way of knowing which blocks can be erased. It would have to analyse the file system metadata and try to determine that, and that's a dirty job. It somehow worked for me (Windows XP + SSD) and it somehow works for disks in RAID arrays (TRIM is not always usable in those).
Uh, no. Completely, utterly, horribly wrong. As has already been explained multiple times in this thread, the operating system doesn't know that files on an SSD are fragmented or not because the SSD controller handles file allocation itself internally and does not need to expose that information externally.
Wow.
Well, the bold part is true, with a small correction: the SSD controller does not understand the concept of files, it only knows logical blocks/sectors. It maps those to SSD blocks and pages, which is one source of fragmentation. That's unavoidable - it makes wear leveling possible. The controller may do some kind of defrag internally, or at least have algorithms to limit fragmentation, but we don't know that, and the OS doesn't know that either.
But there's the other part you didn't mention. If a file is already badly fragmented at the file system level then it's at least as badly fragmented inside the SSD blocks and pages, right?
 
Why does a solid state hard drive slow up when near full if it can just wait till things are quiet?

Because it will begin to exhaust the programmable blocks available. More programmable blocks available means more data can be written at once, which greatly increases write speed ;)
 

Storage Optimizer will defrag an SSD once a month if volume snapshots are enabled. This is by design and necessary due to slow volsnap copy on write performance on fragmented SSD volumes. It’s also somewhat of a misconception that fragmentation is not a problem on SSDs. If an SSD gets too fragmented you can hit maximum file fragmentation (when the metadata can’t represent any more file fragments) which will result in errors when you try to write/extend a file. Furthermore, more file fragments means more metadata to process while reading/writing a file, which can lead to slower performance.

When he says volume snapshots or "volsnap" he means the Volume Shadow Copy system in Windows. This is used and enabled by Windows System Restore when it takes a snapshot of your system and saves it so you can rollback to a previous system state. I used this just yesterday when I install a bad driver. A bit of advanced info here - Defrag will only run on your SSD if volsnap is turned on, and volsnap is turned on by System Restore as one needs the other. You could turn off System Restore if you want, but that turns off a pretty important safety net for Windows.

@Wirko is correct.
Did you actually READ that article? Context is important and you've missed some.
 
Do point out what I have missed - substantiate your assertion.
I'll take a crack at it:
December 04, 2014
There you go. That article was relevant some 8 years ago when SSD's where made primarily of SLC and MLC NAND and sector management was not always handled by the drive controller. The Windows Defrag service does NOT defrag SSD's any longer and hasn't since shortly before that article was written.

Sector management and trim functionality is handled exclusively by the SSD controller universally as of 2016. The OS(any) is no longer involved. This is an industry standard aspect of SSD NAND controllers. Why? Because of NAND cell wear leveling. An OS does not address cell wear leveling as no OS can see that information. All the OS can see is the S.M.A.R.T. data. SSD controllers managing sectors and wear leveling is a necessity for proper sector and cell wear management.

Additionally, there are many who state clearly that no one should ever let Windows defrag or manually defrag an SSD. It is a fundamentally flawed notion.

Even manufacturers CLEARLY state this;

Folks, do NOT defrag your SSD's, doing so will put them in an early grave, will potentially cost you time, headache and money.. Turn the Windows defrag service off and leave it off!
 
Last edited:
I'll take a crack at it:

There you go. That article was relevant some 8 years ago when SSD's where made primarily of SLC and MLC NAND and sector management was not always handled by the drive controller. The Windows Defrag service does NOT defrag SSD's any longer and hasn't since shortly before that article was written.

Sector management and trim functionality is handled exclusively by the SSD controller universally as of 2016. The OS(any) is no longer involved. This is an industry standard aspect of SSD NAND controllers. Why? Because of NAND cell wear leveling. An OS does not address cell wear leveling as no OS can see that information. All the OS can see is the S.M.A.R.T. data. SSD controllers managing sectors and wear leveling is a necessity for proper sector and cell wear management.

Additionally, there are many who state clearly that no one should ever let Windows defrag or manually defrag an SSD. It is a fundamentally flawed notion.

Even manufacturers CLEARLY state this;

Folks, do NOT defrag your SSD's, doing so will put them in an early grave, will potentially cost you time, headache and money.. Turn the Windows defrag service off and leave it off!
The article I linked is not talking about sector management. It is talking about OS filesystem metadata fragmentation.

Please link a clear article describing changed filesystem design in Win 11 if you're so certain that metadata fragmentation is no longer an issue.
 
The article I linked is not talking about sector management. It is talking about OS filesystem metadata fragmentation.

Please link a clear article describing changed filesystem design in Win 11 if you're so certain that metadata fragmentation is no longer an issue.
I don't need to. I did provide at least one MANUFACTURER link that clearly states NOT to defrag your SSD.
To summarize, do not defrag an SSD
The answer is short and simple — do not defrag a solid state drive. At best it won't do anything, at worst it does nothing for your performance and you will use up write cycles.
You're continuing to miss context. I'm not holding your hand on this matter. Figure it out for yourself or continue in ignorance.
 
I don't need to. I did provide at least one MANUFACTURER link that clearly states NOT to defrag your SSD.

You're continuing to miss context. I'm not holding your hand on this matter. Figure it out for yourself or continue in ignorance.
Then better don't use Windows, since Windows does defrag the SSD once a month (ish) to maintain filesystem access speed. The irony of losing context seems to be lost on you.

Go ahead and cripple your own system, just don't advise others to do the same. And learn to swallow ego, some people who are providing the right info aren't doing so to win, only to help others optimise systems properly.

Calm down, read my posts a bit slower and the extracted paragraphs. I doubt you even opened the article I linked. Cos that's what I used to do a couple of years ago when I was about to be proven wrong. ;)

-----

"I dug deeper and talked to developers on the Windows storage team and this post is written in conjunction with them to answer the question, once and for all

"WHAT'S THE DEAL WITH SSDS, WINDOWS AND DEFRAG, AND MORE IMPORTANTLY, IS WINDOWS DOING THE RIGHT THING?"​

It turns out that the answer is more nuanced than just yes or no, as is common with technical questions.

The short answer is, yes, Windows does sometimes defragment SSDs, yes, it's important to intelligently and appropriately defrag SSDs, and yes, Windows is smart about how it treats your SSD."
 
Last edited:
Go ahead and cripple your own system, just don't advise others to do the same.
I disable the defrag service by default, always. Been doing that since the Windows XP days. Have never had a problem. Ever. I will give advice that I know works well as I see fit.
And learn to swallow ego
Take your own advice, thank you.
some people who are providing the right info aren't doing so to win
But you're not and I have already proven this fact.
only to help others optimise systems properly.
You're not helping anyone.
Calm down
Oh? I am perfectly calm. It's silly that you think otherwise. Quit with the personal remarks.
I doubt you even opened the article I linked.
Oh? Then how did I quote that near 8 year old article? I did in fact read it. I then disregarded it as it is old information based on things that no longer apply.
Cos that's what I used to do a couple of years ago when I was about to be proven wrong. ;)
Interesting insight. One critical flaw in your logic: I am not wrong. Defraging SSD's made anytime during the past 6 or 7 years, for any reason, is a very bad idea. Full stop, end of discussion.

You have not proven your assertions. I have proven mine. Quit arguing.
 
That's wear leveling, and your're right, it's probably a bit less efficient when the drive is close to full.
Thanks i forgot the name

The thing here is that DRAMless drives, TLC, QLC etc all make that 'bit less' bigger and bigger

Defrag on an SSD either TRIMs, or is a no-op. Given how smart current SSD controllers are, even the first is likely a no-op because the controller likely treats commands like TRIM that can affect block allocation, and therefore performance, as hints rather than pure "do this now" orders - the controller automatically runs TRIM itself at quiet times when the drive is at low load anyway.


Uh, no. Completely, utterly, horribly wrong. As has already been explained multiple times in this thread, the operating system doesn't know that files on an SSD are fragmented or not because the SSD controller handles file allocation itself internally and does not need to expose that information externally.
Defrag programs can look at the drive and see fragments - they literally see every file as a chaotic crazy ass mess

Windows is smart enough to know the difference and run TRIM instead, but i've seen that break on closed OS's in the past - cloning mech to SSD, and then windows defragged the SSD

Heres defraggler, an up to date still commonly used program

1660360624280.png


Oh no my nvidia driver
1660360653970.png




An OS doing a cleanup of caches, is not defragging them - that's deleting whatever existed, created a new copy without un-needed fluff and then the new version gets written with less fragments - if space permits

It gives you optimise and defrag options, which uhhh... not great for beginners?
1660360726272.png




Oh god optimise is not TRIM
1660360756550.png


Well thats a start
1660360781830.png


Why does a hard drive slow up when near full if it can just wait till things are quiet?
1. Because they're a circle, and the outside of a circle spins faster, so its got lower access times

2. because you dont have space to write new files in a single solid line (Contiguous file, mmm fancy words), so not only are the files in a slower part of the disk they're more heavily fragmented too.

And... how long is it meant to wait?

If you're writing 5GB of small files and it's writing away at 10MB/s since they're fragmented and messy (Yes, they can get slower than that) you could be waiting hours for the drive to 'not be busy' - they have like 64MB of cache, not enough to outlast that sort of thing.
SMR drives can be even worse.


Defragmenting is literally grabbing a file in it's smaller pieces, and sticking into an empty part of the drive with enough room to fit the entire file in one solid piece.
A drives access time could be 20ms, so a 500 piece file could have 10,000ms of idle wait time for the drive to seek between its parts, and i've had large files (BD rips, 40GB+) have tens of thousands of fragments

Over time defraggers got fancy enough to 'consolidate files' which meant finding already contiguous files, and moving them to empty spaces near the start/outer edge of the disk - the worst offenders (small files) got a speed boost (access times are fastest near the spindle), with lots of free space for large files at the far end

Ultimate Defrag was great at visualising this
(Not my screenshots, source was blurry AF. blue/red/green is what we care about here)
Normal drive:
1660361256593.png


optimised drive
(You could set folder locations for performance and archive, aka outside and inside)
1660361323064.png
 
Last edited:
The article I linked is not talking about sector management. It is talking about OS filesystem metadata fragmentation.

Please link a clear article describing changed filesystem design in Win 11 if you're so certain that metadata fragmentation is no longer an issue.
Hi,
Win-11 is not main stream and has only about the same luddies using it as us win-7 users :laugh:
 
Oh i figured a better answer for the OP's original question, thanks to UDefrags images below

A partition on a mech disk, gives the first partition the best performance. It's dividing a circle into rings.

An SSD is spread over various NAND chips - but a 10% sized partition doesnt say okay C: is NAND 1, and D: gets 2 through 10 - it gives C: 10% of each NAND chip




My bad... force of habit... I meant

Why does a solid state hard drive slow up when near full if it can just wait till things are quiet?
Because it has to erase things to write - and it needs enough free space and time to erase a stack to write the original + new data
Do that enough times (especially with smaller files, wasting writes) and it's not a fast process

Using a RAM cache like with primocache can alleviate that stress, if you trust your stability


Hi,
Win-11 is not main stream and has only about the same luddies using it as us win-7 users :laugh:
W11 is mainstream - just because it's slow on things like steam (where half the users are using core 2 duos and onboard graphics in windows XP) doesnt mean it's not mainstream

Then better don't use Windows, since Windows does defrag the SSD once a month (ish) to maintain filesystem access speed. The irony of losing context seems to be lost on you.

Go ahead and cripple your own system, just don't advise others to do the same. And learn to swallow ego, some people who are providing the right info aren't doing so to win, only to help others optimise systems properly.

Calm down, read my posts a bit slower and the extracted paragraphs. I doubt you even opened the article I linked. Cos that's what I used to do a couple of years ago when I was about to be proven wrong. ;)

-----

"I dug deeper and talked to developers on the Windows storage team and this post is written in conjunction with them to answer the question, once and for all

"WHAT'S THE DEAL WITH SSDS, WINDOWS AND DEFRAG, AND MORE IMPORTANTLY, IS WINDOWS DOING THE RIGHT THING?"​

It turns out that the answer is more nuanced than just yes or no, as is common with technical questions.

The short answer is, yes, Windows does sometimes defragment SSDs, yes, it's important to intelligently and appropriately defrag SSDs, and yes, Windows is smart about how it treats your SSD."
Your answers here are good - yes fragmentation can still occur, windows will defrag individual files if neccesary under specific circumstances - but not by the same rules as defragging a mech drive

You guys don't need to fight over this one - although i've had similar arguments with lex on other topics. He's fine to say what he does on his systems and why, but often gives advice that while fine for him could have negative complications for others. I think it's a matter of defending his choices, and simply poor wording at times
 
Last edited:
Hi,
Only main stream os I see here is win-10

1660362008509.png
 
Not arguing, but was curious since actual Windows developers were suggesting that Windows defrags SSDs. From what I’ve read it defragmentation the metadata of the file system, which the controller is unaware of, due to limits in various file systems about how much metadata can be stored based on the block size. The premise seems logically sound to me, but I don’t know enough about file systems to understand why metadata would need to be defragmented on flash based storage.

Looking into it further, I found this doc that says defrag will defragment an SSD as of 2021:

But optimize-volume will skip defragmentation on SSDs?

This IT guy says it does happen, but only when the fragmentation threshold is reached, like that old Hanselman article suggests:

There’s also this recent bug where windows defragmented ssds too often but at this point I’m not even sure what’s being defragmented:

But… why? Didn’t Windows 8 (IIRC) increase maximum file size to some absurd number (200GB+?). When would the metadata become an issue when Windows has exceeded NTFS limitations in it’s implementation and RAIDs aren’t defragged?

Well thats a start
1660360781830.png
I’m even more lost now lol, never tried to defragment a SSD but good to know
but not by the same rules as defragging a mech drive
This makes sense to me, but why aren’t they documenting the difference? I saw a user on OCN who’s SSD had 5% fragmentation, then ran defraggler, but only saw a 1% write increase relative to drive space used, which might suggest a difference in how mediums are handled, but I’ve never done this math on a HDD.
 
Last edited:
Oh i figured a better answer for the OP's original question, thanks to UDefrags images below

A partition on a mech disk, gives the first partition the best performance. It's dividing a circle into rings.

An SSD is spread over various NAND chips - but a 10% sized partition doesnt say okay C: is NAND 1, and D: gets 2 through 10 - it gives C: 10% of each NAND chip





Because it has to erase things to write - and it needs enough free space and time to erase a stack to write the original + new data
Do that enough times (especially with smaller files, wasting writes) and it's not a fast process

Using a RAM cache like with primocache can alleviate that stress, if you trust your stability



W11 is mainstream - just because it's slow on things like steam (where half the users are using core 2 duos and onboard graphics in windows XP) doesnt mean it's not mainstream


Your answers here are good - yes fragmentation can still occur, windows will defrag individual files if neccesary under specific circumstances - but not by the same rules as defragging a mech drive

You guys don't need to fight over this one - although i've had similar arguments with lex on other topics. He's fine to say what he does on his systems and why, but often gives advice that while fine for him could have negative complications for others. I think it's a matter of defending his choices, and simply poor wording at times
Thanks for being a voice of reason.
I had already decided to stand down and not bother fighting, right before seeing your post, but for the record I'm not backing down from sharing the knowledge I've gained when I myself was confused during the transition period from HDD to SSD. My first SSD was a Samsung 830, 256 GB.

I'm not advocating a user go and seek out a way to run a HDD style defrag on their SSD. I'm simply saying to trust that Windows 10/11 are designed by rational, competent engineers in the Storage team, and there's no need to "help them further" or "disable defrag, it's of the devil".

Just choose how regular one prefers the default disk maintenance tool to run trim/retrim, and then forget it.

Going to see how primocache works, thanks! I'm currently using IMDisk to create a RAM disk as temp drive, dynamically allocating up to 4 GB for this purpose.
 
I'm simply saying to trust that Windows 10/11 are designed by rational, competent engineers in the Storage team, and there's no need to "help them further" or "disable defrag, it's of the devil".
The problem with that statement is that drive manufacturers advise against defragging an SSD. Windows itself warns against it. Common sense says those two examples are enough.

I’m even more lost now
As the old saying goes, when in doubt, don't.

What more does one really need?
 
Back
Top