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
Because file deletion is a logical process, where the file entry in the MFT and the cluster bit map is updated. The file's data pages are not touched. So all the SSD controller sees is a couple of pages being updated (it doesn't 'know' that these are the MFT and cluster bit map). The data pages are still considered to be in use.
A TRIM (optimise) will correlate the cluster bit map to the SSD pages, and flag any page not marked as live in the bit map. The SSD controller will remove the page from its mapping tables, and free space will thus increase.
I'm surprised that an optimise produces any noticeable increase in free space. Do you have TRIM enabled on the SSD and O/S? This should do the optimisation for you.
File deletion is just the same on HDD's, but there you can just write on any cluster, live or deleted. Only on SSD's do you have to run a page deletion process (TRIM) before space is freed.
how much space are we talking here?
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.
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.
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?
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.
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
Anybody???
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?
- This article provides SOME details.
http://blog.superuser.com/2011/05/10/maximizing-the-lifetime-of-your-ssd/
NTFS
WIndows 7 Pro
Downloaded the crystal diskinfo and it shows Trim enabled.
Ran the FS UTil and it shows Trim Enabled.
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.
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.
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.
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
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?
It is an internal SATA Drive. I have not timed it, but would guess 5-10 minutes or so.
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.
No real experience in this area but thought I'd throw this bit od reading in Keith
http://www.howtogeek.com/165472/6-things-you-shouldnt-do-with-solid-state-drives/