Intel SSD Thinks it's full: it's not

JSquid

Gawd
Joined
Mar 2, 2001
Messages
766
This problem has arisen a couple times in a 2 different Intel X-25 160gb drives. The drives eventually begin to show they are more full than they actually are.
NH1gA.jpg


I can't find any reason that this would happen. I had BitLocker on and encrypted but have since disabled it and decrypted the drive.

Any thoughts?
 
This came to mind:

http://www.enterprisestorageforum.com/technology/features/article.php/3850436

Are you running the newest firmware update from Intel? ...and "Rapid Storage Technology" drivers that were just updated? AHCI enabled on the motherboard?

I know that the older drivers don't have TRIM implemented, so that could be part of the problem.

Also, the SSD Toolbox should help some (if you aren't using it).

Those are just my thoughts: TRIM/garbage collection isn't working as it should because the written space isn't being reclaimed.

Looking at the new specs to the G3 Intel drives (which specifically support encryption), the G2 could be confused after having Bitlocker enabled. (Just a thought, I'm not 100% certain of how well the G2 works with Bitlocker.)

Here's a link to G3 specs which make a big deal of encryption support:

http://www.anandtech.com/show/3965/intels-3rd-generation-x25m-ssd-specs-revealed

I'd tell you to backup the drive, do a secure erase (using the Intel SSD toolbox), update the firmware if it needs it and then reinstall everything without Bitlocker. The secure erase will reclaim all space.
 
You're on the wrong track. A block device has no idea whether it is full or not. The OS and the filesystem are what keep track of how full a block device is.
 
You can't get an accurate reading In TreeSize because it can't read the System Volume Information folder, which is where the rest of the data (restore points) most likely is.
 
You're on the wrong track. A block device has no idea whether it is full or not. The OS and the filesystem are what keep track of how full a block device is.

Yes, but an SSD works differently than traditional storage. Here's a quote from the first article:

"SSDs suffer from a difficulty that doesn't exist in HDDs — the flash must be erased before new data can be written into it," said Jim Handy, an analyst at Objective Analysis, a market research firm that predicts 148 percent unit growth for the enterprise SSD market.

Flash's Software Problems
Handy said the erasure difficulty stems from the fact that all of today's software was written for HDDs, which don't behave like the flash in an SSD.

"An HDD can overwrite existing data with new data," said Handy. "Since the software doesn't accommodate flash's 'erase-before-write' needs, the controller inside the SSD must take care of this bit of housekeeping. Unused and unerased blocks are moved out of the way and erased in the background."

If the drive doesn't support encryption (as I think is the case), this could be what's causing the disk space to be blocked from being reclaimed and being shown as full.
 
You have space claimed by Restore Points and other stuff; has nothing to do with free space and the SSD.

The SSD does roughly know how full the drive is though; a 0% full drive has 100% spare space, a 50% drive has ~50% space space; basically any space you write to is claimed and thus used by the OS, until it is TRIMed and given back to the SSD again.

Furthermore, there's a different between actual file size, and size on disk. Since all storage is a multiple of the sectorsize, that means that you will have slack or space that cannot be fully utilized. This happens alot when you have lots of small files, where the size on disk could be double that of the real filesize of all small files combined.
 
Yes, but the point is: these are just files stored on the SSD; there is no space lost; it's in use. You probably can't see hidden system files or something; but they're definitely there.

If you have alot of RAM on 64-bit platform consider dropping the hibernation and pagefile altogether; you won't need swapping anyway (typical apps are 32-bit so limited 2GiB each; which makes memory shortage on high-mem systems a very rare event), and hibernation isn't that sexy when you got ALOT of memory; then the shutdown and power up would take quite a bit of time. So disable that too. :)
 
This thread title reminded me of Jerry Springer

And next time.... Seagate RAID arrays that won't initialize... claims WD still owes child support!!
 
Yes, but an SSD works differently than traditional storage.

You are confusing the issue. The fact that SSDs keep track of valid and invalid pages has nothing to do with the fact that a block device such as an SSD (or HDD) has no idea whether the filesystem is full or not. That is handled by the OS.

The problem in the OP has to do with the OS, not the SSD.
 
Yes, but the point is: these are just files stored on the SSD; there is no space lost; it's in use. You probably can't see hidden system files or something; but they're definitely there.

If you have alot of RAM on 64-bit platform consider dropping the hibernation and pagefile altogether; you won't need swapping anyway (typical apps are 32-bit so limited 2GiB each; which makes memory shortage on high-mem systems a very rare event), and hibernation isn't that sexy when you got ALOT of memory; then the shutdown and power up would take quite a bit of time. So disable that too. :)

Yeah, I realized that after you mentioned system files that he wasn't using Windows Explorer to view the drive.

I linked the article because I've never seen any mention of disabling hibernation in any SSD articles. I just disabled hibernation and pagefile and recovered about 10gb, which is a lot considering that my total space is 80gb (on the SSD).

This thread title reminded me of Jerry Springer

And next time.... Seagate RAID arrays that won't initialize... claims WD still owes child support!!

Hahaha!

Intel tells Kingston: I am NOT the father...
 
Back
Top