Jump to content
CCleaner Community Forums
keithg

Optimize SSD, and free size is increased each month

Recommended Posts

I do an optimize on my SSD drive once per month, and each month after running I gain space.  Why is this? 

 

Makes not sense to me as in my decades of defragging Hard drives this was not the case.

 

Keith

 

 

Share this post


Link to post
Share on other sites

5 to 10 GB normally. 

Drive is an 180 GB SSD

 

Ran optimize twice back to back and here are the results.    (Empty Recycle Bin First)

Free space: 46.336 GB

Ran Optimize

Free Space: 62.463 GB

Ran Optimize

Free Space: 62.458 GB

 

I don't know how long it has been since I ran optimize.

Share this post


Link to post
Share on other sites

and just confirming, this is the Optimise button in DF and not the Optimise button in Windows File Explorer?

 

definitely the Windows Optimise doesn't reclaim space, it simply triggers the TRIM command.

I use it every month or so.

if you are doing the DF Optimise, then it looks like it's doing more than that.

 

Perhaps your SSD is not TRIM-capable and DF is using the alternate zero-fill method to 'trim' the SSD, but still, that's a lot of gigs getting reclaimed.

Share this post


Link to post
Share on other sites

Yes running defrag optimize in defragger.

(Not sure what the optimize button in Windows File Explorer is.

 

Drive in question is:

 

               Intel Series 330 180 GB

 

Per this command Trim is enabled:

 

fsutil behavior query DisableDeleteNotify

DisableDeleteNotify = 0

 

When I run defrag optimize it does give me the message about zero-fill your drive.  Is not the normal message?

Share this post


Link to post
Share on other sites

My first thought was that this is something to do with TRIM, but then I thought a little more. Used and Free Space measurements aren't done by going to the device, they are calculated by NTFS.

 

How are you measuring the space used? If you are in Explorer and right click on the SSD drive letter and select Properties then NTFS will go to the cluster bit map, count the in-use bits, and multiply them by the cluster size. This is measuring live files allocated by NTFS, not counting clusters or pages on a storage device. If the cluster bit map is in memory then no device access is required at all. The SSD knows nothing about NTFS or files, it just reads and writes pages as requested. So TRIM or not wouldn't make any difference to the space used/free as displayed by Explorer.

 

I suppose it's possible that Explorer/NTFS/Windows recognises that this is an SSD so goes to the disk and requests a count of mapped pages, but I very, very, very much doubt it as that would give a false result.

Share this post


Link to post
Share on other sites

I am getting the free space from the command line command dir.    That free space matches freespace reported by defraggler.

 

Going to rerun optimize again(last ran 4 days ago)

Free Space Before: 55.8 GB (As reported by defragger)

Free Space After:    55.9 GB (As reported by defragger)

 

Very little change(Computer was not used much between defragging)

 

Keith

Share this post


Link to post
Share on other sites

Unfortunately we don't know all the answers. Your last Optimise (post 7) doesn't show any appreciable increase in free space.

 

Stepping back a little, is your file system NTFS or FAT32? And what's your O/S?

Share this post


Link to post
Share on other sites

As I elaborated in post 6, if you want to know how much space is being used on a storage device you don't look at the device. Storage devices do not recognise the existence of files. An HDD will just have millions of sectors, and an SSD will have a number of pages mapped, and the rest unmapped. Those mapped pages may nor may not contain live files, the SSD controller doesn't know how many, or even know what a file is. So on that basis I'm discounting the effects of TRIM.

 

A file is a collection of clusters, or SSD pages, as described in the MFT. Total space used is defined by the status of bits in the cluster bit map. If you click on the drive letter in Explorer and select Properties then NTFS will count the number of bits in the cluster bit map set to 1, then multiply that by the cluster size. If you select a number of directories in Explorer and select Properties then NTFS will look at the space used of those directories, which will give a different result from clicking on the drive letter. None of this is affected by TRIM.

 

I don't know why you are using the command line to show space. Isn't that some sort of cobbled up facsimile of DOS? I've no idea what tortuous path that uses to show space. Probably it would be better to interrogate the drive letter in Explorer.

 

After all this I have no idea why the space varies after an Optimise.

Share this post


Link to post
Share on other sites

Actually I was using a program from JP Software (https://jpsoft.com) called Take Command. If you do not know the power of the command line, do not criticize it.  It is probably more accurate than Explorer.

 

Keith

 

PS I don't think you need to explain how a HD stores files to anyone that mentions using the command line. 

Share this post


Link to post
Share on other sites

Well, if you don't tell us what software you're using then we have to guess. What makes you think that third-party software is more accurate than Explorer?  More relevant is that using a specific piece of software rules out any help from those who don't have it.

 

I've not explained how a HD (let alone an SSD) stores files, I've tried to explain how space is calculated and why I don't think that TRIM affects your problem. The forum is read by many people whose skill levels, like yours, is unknown.

Share this post


Link to post
Share on other sites

I have compared the free space reported by the command line(JP Software Take Command) and defragger itself and they both report the same information, and both report an increase of space after running the optimize. I think the above prior result that did not shown an larger increase was due to the fact that it was ran shortly after running optimiize prior.

 

Last Ran: August 8,2016

Numbers from Defragger:

Before: 61,669,732,352 (57.4 GB)

After:    58.949.812.224 (54.9 GB)

 

So this time I lost space.  This does not make any sense.  This is the first time I have seen this.

 

Note freespace does go to or near zero while running.  Is this normal for an trim enabled SSD?

 

Keith

Share this post


Link to post
Share on other sites

From the zero-fill message mentioned in post 5, and freespace going to zero, I suspect that Optimise might be doing a zero-fill operation instead of a volume TRIM. How long does the Optimise take?

 

How is the SSD attached? Is it via a USB port?

Share this post


Link to post
Share on other sites

It could be that Defraggler is running a zero fill. Even though TRIM is flagged as enabled, there may be other factors that are stopping its execution. TRIM is a command that doesn't require and doesn't get a verification response, so it can quite happily be dropped with no complaint from the O/S or file system. If a zero fill is taking place, could it be that some of the system files, shadow copies etc, are being deleted when the volume fills? Perhaps someone with more experience in this can chip in.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...