PS3 Ps3, lack of Trim and the potential for ssd use.

ashura said:
actually it was on the time that i tried to use that specific type of ssd, some time i used to install the ssd crucial bx500 and that one was properly installed but not working as i wanted to, but yep, the dram that the adata su650 has may be most probably one of the reasons of that error that actually was not random on that moment
Click to expand...
The SSD I have has no DRAM but still gives the error, but everything else seems to work fine.
 
that good and also the same time weird, unfortanely i do not know yet if there is a compatibility list of ssds from ps3, so far i saw that the mx500 and bx500 models from crucial they do work fine
 
Some information about TRIM or UNMAP(in SCSI speak).
Unlike HDDs, SSD devices do not expose the physical LBAs to a host, instead they keep an internal mapping between the LBAs that they expose to a host and what LBAs this translates to on the physical media.
This means that if an application writes to LBAs 1,2,3,4 sequentially. That might not end up being sequential on the physical media, and most of the time will not be. So, this could translate to physical LBAs 4,27,1,9 and there is no way for the host to even know this mapping.
One astute observation here is that this means that it is pointless to "defragment" an SSD device. And it is. But since there is no rotational latency involved the cost for seeking is essentially zero, so reading random physical LBAs is just as fast as reading physical LBAs sequentially.

How does this help with wear-leveling? The idea is that in a filesystem, when you delete a file the filesystem can generate a TRIM/UNMAP command and send to the device which would then release the mapping for these LBAs so that next time these LBAs are written to the device can pick a different physical block and assign it to the mapping. Thus the interaction between a trim/unmap aware filesystem and the device could help with wear-leveling. The very first generation of SSD devices depended on this.
Of course at the time there were no such trim/unmap aware filesystems on any platform so trim/unmap was mostly pointless. And device manufacturers instead had to add code to the firmware itself to rotate the mapping of hot blocks across physical LBAs.
ALL devices today do this so you don't need trim/unmap for wear-leveling. There is zero reason to worry about lack of trim support in ps3.

Now comes the fun part. So, when you release the mapping for an LBA and there is no physical LBA mapped to that logical LBA (the mapping is only created once you write to an unmapped LBA). If you read an unmapped LBA the device will return all zeros for the block. Good ha? So now we have a useful command to bulk "zero-out" ranges of LBAs. Yeah, well, updating these mapping tables takes a little time, not much, but enough that it can affect benchmark results, so since both trim/unmap are only advisory vendors often/always just tream trim/unmap as a NO-OP if the device is busy. Many vendors even treat trim/unmap as a NO-OP all the time. Because the standard allows it and a NO-OP will always be faster than a not-NO-OP in benchmarks.
So this means you can not depend on trim/unmap to actually make a block read back as zero anymore. The raid-subsystem on linux learnt this the hard way and it started causing massive amounts od data corruption (because if trim/unmap becomes a NO-OP, then any zeroing out of blocks using it will essentially lead to all the parities being wrong and the raid will fail)
So, trim/unmap is no longer actually used tfor that anymore. Other different commands are used instead. Much slower commands but commands that actually guarantee that the data will be read back as zero (WriteSame10/16 for SCSI, don't remember the command name for ATA).
Filesystems still issue trim/unmap commands to the device for cases when it does not matter if it is a NO-OP or not (i.e. the non-raid case) but it is just a hint. The ssd can just ignore the command if it wants to.

TL;DR: SSD devices except the very first generation no longer need/depend on trim/unmap anymore. Most actually implement them as a NO-OP. Implementing trim/unmap on PS3 would be a waste of time.
 
Iridule said:
do you think what @Berion has here would not work then? "Second hidden task is for invoking TRIM command on user partition but since I don't have SSD in PS3 and I don't even know if can be done on UFS2, I also hide it ("wip-2", needed ufs.ko with rw permission)." https://www.psx-place.com/threads/ps3-hdd-decryption-helper.38281/page-2#
Click to expand...

The reason I say I think it would be a waste of time is because the devices no longer need trim/unmap in order to do wear-leveling.
And since they no loner need it most vendors implement trim/unmap as a NO-OP because it is beneficial to benchmarks.
 
Ronnie Sahlberg said:
The reason I say I think it would be a waste of time is because the devices no longer need trim/unmap in order to do wear-leveling.
And since they no loner need it most vendors implement trim/unmap as a NO-OP because it is beneficial to benchmarks.
Click to expand...
I see. What do you suppose may be causing my random "insert proper storage media" error could be? no way to reproduce it and when it does happen a restart fixes it.
 
Iridule said:
I see. What do you suppose may be causing my random "insert proper storage media" error could be? no way to reproduce it and when it does happen a restart fixes it.
Click to expand...

Hard to say, but SSDs sometimes draw more power. Does it only happen on a cold start? Speculation, could be it draws too much power for the ps3 and needs to wait until some capacitor charged up.
 
Ronnie Sahlberg said:
Hard to say, but SSDs sometimes draw more power. Does it only happen on a cold start? Speculation, could be it draws too much power for the ps3 and needs to wait until some capacitor charged up.
Click to expand...
No... In fact the first time it happened I thought it was a CFW error because instead of rebooting normally I just used a shortcut from the CFW menu. There's no way to reproduce it 100% of the time it's random.
 
@arcadekidflo
Minimal 480/500GB less have no sense (1TB is optimal for Me). DRAM = better performance especially when copying/installing large games, TLC 3D Nand + good ssd controller inside.
 
In very earlier models, CECHA for example, the south bridge doesn't even have a sata port. The sata hdd was connected through a sata-> pata converter ic. later ones starting with slim models, if I'm not mistaken, they replaced the SB with one witch had sata ports for both hdd and bd. This could be a huge difference in ssd compatibility through different motherboard variations. Isn't it?
 
Dariush Aghaee said:
In very earlier models, CECHA for example, the south bridge doesn't even have a sata port. The sata hdd was connected through a sata-> pata converter ic. later ones starting with slim models, if I'm not mistaken, they replaced the SB with one witch had sata ports for both hdd and bd. This could be a huge difference in ssd compatibility through different motherboard variations. Isn't it?
Click to expand...
I never thought in it before but yeah, good point
In the same way the SATA2USB controllers of the external HDD enclosures for PC could be problematic, the PATA2SATA controller of some PS3 models (CECHKxx/DIA-002 or older) could be problematic for SSD's

Is an important detail to consider when we are reading compatibility reports of SSD's for PS3, we need to ask about the PS3 model to figure if is a direct connection (SSD<->SB) or there is a controller in between them (CECHKxx/DIA-002 or older)

-----------
EDIT:
Hmmm, no, wait, the PATA2SATA controller of old PS3 models was dedicated to the Blu-Ray only (not the HDD)
The HDD has been always a direct connection to SouthBridge in all PS3 models


-----------
EDIT2:
Anyway, now we are talking about it.... the southbridge model could interfer with the SSD compatibility, this is another detail to consider, there are only 4 southbridge series:
https://www.psdevwiki.com/ps3/South_Bridge
* CXD2973xxx Series <----- SPIDER DX
* CXD2979xxx Series <----- SPIDER PX
* CXD2984xxx Series <----- SPIDER SX
* CXD9963xxx Series <----- SPIDER ZX
 
Last edited:
sandungas said:
The HDD has been always a direct connection to SouthBridge in all PS3
Click to expand...
No it hasn't. In the CECHA the SB has only pata ports. The hdd connects through a converter while the optical drive is IDE and connected directly to the SB.
Hmmm, no, wait, the PATA2SATA controller of old PS3 models was dedicated to the Blu-Ray only (not the HDD)
Click to expand...

Actually in later models they was. In those models $ony replaced the SB with one witch had only sata ports. But they still stuck with the IDE blue ray drives. So they used the same converter ic for optical drive this time. Later they integrated the converter in the bd daughter board.
 
Dariush Aghaee said:
No it hasn't. In the CECHA the SB has only pata ports. The hdd connects through a converter while the optical drive is IDE and connected directly to the SB.


Actually in later models they was. In those models $ony replaced the SB with one witch had only sata ports. But they still stuck with the IDE blue ray drives. So they used the same converter ic for optical drive this time. Later they integrated the converter in the bd daughter board.
Click to expand...
To be honest, i never paid much attention to the weird details of the PS3 fat models (i prefer slims) but im looking at the service manuals and you are right (there is some info in wiki wrong and misleading though)

* CXD2973xxx Series <----- SPIDER DX <--- BD is direct IDE, and HDD through 88SA8040
* CXD2979xxx Series <----- SPIDER PX <--- BD is direct IDE, and HDD through 88SA8040
* CXD2984xxx Series <----- SPIDER SX <--- HDD is direct SATA, and BD through 88SA8040
* CXD9963xxx Series <----- SPIDER ZX <--- HDD is direct SATA, ¿ and BD is direct SATA too ?

The CXD2984xxx with SATA ports was introduced for first time in CECHGxx/SEM-001, so the only motherboards without a direct SB<->HDD connection (could be problematic for SSD compatibility) are COK-001 and COK-002
And right now i dont know if/when the 88SA8040 was moved from main motherboard to BD daughterboard

https://www.psdevwiki.com/ps3/South_Bridge
https://www.psdevwiki.com/ps3/SATA/PATA
https://www.psdevwiki.com/ps3/88SA8040-TBC1
 
Last edited:
thnaks a lot sandungas for this information. btw i have a question, i do have a slim ps3 console already with cfw, i wanted to do an upgrade maybe to a SSD, i do have actually a 500gb hdd 7200 rpm with 32mb disk cache is a hgst hitachi model it goes good but still i wanted to see if maybe a good choice can be to use a mx500 crucial 480gb SSD, my model is a CECH-2101B, thanks a lot and have a nice day
 
Crucial MX500 is a solid choice. I've been running one in my CECHE01 for several months now, no issues. It's 1TB filled 90% and still performing well.
 
Alonso240 said:
Crucial MX500 is a solid choice. I've been running one in my CECHE01 for several months now, no issues. It's 1TB filled 90% and still performing well.
Click to expand...
And it passes the screen where the PS3 does a filesystem check ? (in the next reboot after a crash or freeze)... or are you skipping that filesystem checks ?
 
You must log in or register to reply here.

Similar threads

Back
Top