PS3 How much space should i leave empty on my PS3 SSD?

[DTR]

So as not to incur any performance penalties or cause any issues.

I never thought i would have this problem, especially since i actually buy my games, but here we are.

I have a 1TB SSD on the PS3. To keep things simple, how much should "free space" say in system information so the thing is running at max performance at all times? Is 200 GB free doable and sustainable without any performance hits or risk of corruption? I am now sitting at 300 GB free space and since i still plan on getting some more games i am starting to panic. I already deleted some data from games that i realistically will not be touching again but it still felt bad doing it. I think if i get all i have planned plus change for DLC and the space needed to install it i will for sure pass the 250GB free mark.

With every new post i read on the subject the percentage goes up by 5%, to the point that the record I'm at is 35%. That sounds honestly ridiculous, does it have any basis? Also when it comes to percentages do i subtract from the total free space (931) or the free space after the OS reserves it's portion for cache and whatnot (828).

Thank you.

 

[Metroid_Hybrid]

Over the years, I've always heard ~10% free space as a rather consistent standard in the world of HDDs & SSDs. I'm currently sitting at a little below that in the SSD in my PS3. I also run everything from the SSD, in order to help preserve the laser in my stock Blu-ray drive..

Personally, I subtract from what shows up in [System Settings –> System Information], which may be 931 (it is for me). But where are you getting the number 828?

The main problem with SSDs in a PS3 is apparently the PS3's lack of a "TRIM" protocol to keep everything optimized. I've attempted to circumvent this shortcoming by running the "Check File System" a couple times a month, and running the "Rebuild Database" whenever I've deleted a significant amount of data.

 

[Berion]

@DTR You don't need any free space because SSD fw don't know which is occupied and which isn't.

@Metroid_Hybrid 1TB = ~931GiB. Minus 2GiB for cache partition, minus 256 for VFLASH partition (NOR models only), minus 10% of user partition total size. Which results in ~836GiB free space on clean PS3 HDD.

 

[witek-pl]

There is about 50GB of free space on my 1TB Crucial MX500.I don't see any visible side effects so far... On cheap drives you may experience visible a drop in speed, especially writing, when you pass 80% capacity.

 

[DTR]

@DTR You don't need any free space because SSD fw don't know which is occupied and which isn't.

Dude this can't be true. There's multiple anecdotal reports of SSDs corrupting on PS3 when they get filled too much. SSDs need some empty space to do garbage collection and wear leveling.

Maybe there was no need to panic yet and i did not have to delete all that data...Now i am regretting it.

I don't know if checking file system and rebuilding the database actually does anything unless there is some sort of data corruption.

 

[Metroid_Hybrid]

I don't know if checking file system and rebuilding the database actually does anything unless there is some sort of data corruption.

I don't either. But I also have yet to see anything, one way or the other, on that particular subject either... anecdotal or otherwise..

So I figured that some kind of an attempt at regular maintenance, along with backing up my save data every so often, is better than nothing..

 

[Berion]

Dude this can't be true. There's multiple anecdotal reports of SSDs corrupting on PS3 when they get filled too much. SSDs need some empty space to do garbage collection and wear leveling

SSD don't know where PS3 write something. It knows only which pages are unused and these can be used for wear leveling. If you write every sector at least once yet have free space, for SSD are all in use because it not understanding logic structures on user data area on disk.

SSDs on PS3 dying for various of reasons. Many are just not compatible. Some have 4K sectors without internal 512 emulation which leading to UFS2 corruption by design (Sony never add support for it). Another example; SSD cannot be used as cold storage by nature of NAND cells. If such person left PS3 for few years untouched, when will go back, he probably got broken filesystem(s).

I don't know if checking file system and rebuilding the database actually does anything unless there is some sort of data corruption.

Filesystem checks can tell you (actually not telling you anything because Sony not implemented any feedback to the user, all jobs are done silently for the user) only if all filesystems on all partitions are fine, or if not fine but fixed, or if not fixable.

Rebuild database, deleting databases and creating new. Completely not related to filesystem.

 

[Metroid_Hybrid]

...SSD cannot be used as cold storage by nature of NAND cells. If such person left PS3 for few years untouched, when will go back, he probably got broken filesystem(s).

EEK!

Filesystem checks can tell you (actually not telling you anything because Sony not implemented any feedback to the user, all jobs are done silently for the user) only if all filesystems on all partitions are fine, or if not fine but fixed, or if not fixable.

Rebuild database, deleting databases and creating new. Completely not related to filesystem.

So does running the "Check File System" and/or "Rebuild Database" every-so-often provide any benefit from a maintenance standpoint?

And if not, is there anything that does?

 

[Berion]

@Metroid_Hybrid
Surprise?

Rebuild Database is pointless for that goal. Restore FileSystem from recovery (vel fsck) have some sense but not as maintenance procedure. To checking disk health, just check periodically S.M.A.R.T. report. To check logical structure, best be FreeBSD fsck because you getting feedback from it. But it is so annoying to setup (exposing decrypting mapper as device on Linux to virtualised FreeBSD) that it is more like curiosity. We really need such service tool on vsh level, or even better as plugin (S.M.A.R.T monitoring in real time, fsck periodically, user defined interval, read only).