I agree that local time doesn't matter but for a slightly different reason in addition to the UTC one you gave. You'll notice that many people are saying that they didn't have this issue when others have, only three hours later to say they now have it. I believe that this may be due to the hardware clocks running at different speeds in each system. In *nix systems the software clock normally adjusts for the HW clock differences whenever we reset them. It uses a file with some stats on how much the software clock needed to be adjusted in order to determine how much off of real time the HW clock is running. On system startup it reads the HW clock and this file to determine the time to which to set the software system clock.
For those of us that hit this on 28 Feb I'm guessing our hardware clocks were running fast. Those that took longer to hit it may have had HW clocks that were running slow.
Just realized that the local trophy DBs are likely per-game. Since I didn't access the other game that has trophy data since my last sync that data isn't affected. It's probably only upon accessing the per-game trophy data that it notes it as corrupt and possibly deletes the entries. At least that's my latest guess.
I don't think it has to do with games requiring an active network connection. My system hasn't been connected to the internet (no ethernet cord even plugged in) for over a month and I hit this when starting games that have trophy support.
So, I don't think this has anything to do with an internet connection, just had hardware clock bug that some software modules are barfing on. I think most people first noticed this when trying to connect to PSN, but it's likely the handshaking that's having the issue. However, for me, since I'm not trying to even signing on to PSN it's the trophy registration module is having this issue, which has little to nothing to do with trophy server sync but likely is rather for accessing the local trophy DB. As Sony mentions in their blog, I've lost the latest trophy data from my system (although not all the trophy data since my last server sync). I'm not sure why they seem to have two levels of trophy storage unrelated to server sync though.
You are pretty close on all this. Yes, modern flash firmware should use a reservoir of replacement sectors to fill in for bad ones. Even HDD do this to some degree but I believe limit it to nearby regions. Flash firmware has less of a dependency on location of the bad blocks. It's firmware dependent, so may be limited to sectors in blocks on the same chip when choosing replacement sectors. On most modern firmware there should be no limitation though.
As for write power failure of SSD, modern flash firmware is more transaction based and should recover from this. You may lose the data that was being written at the time of the power failure, but previous data and the firmware datastructures should still be in good shape. However, I'm sure there's still much flash sold on the market that doesn't handle power failures on write; I just hope that they aren't used in SSD's.
Obviously, you can also eventually run out of replacement sectors. At that point it's firmware dependent as to what will happen. Flash cells could start wearing out and being lost at this point as there's nothing to replace it. Even before this point if several flash cells in a sector (or whatever is protected by ECC) fail catastrophically it may be that even ECC can't help the data recovery when writing a replacement sector.
A point that many seem to miss here though is that flash has a history stored in it automatically. Because of the nature of flash, you don't actually write the cell that currently holds the data you want to modify. Instead you actually write a different sector. Due to time and power concerns, the original data will not be erased immediately, but instead at a later point in time. In the meantime the firmware knows to take the more up-to-date version of your data when a read is requested on its logical location.
Hence, in theory, the best chance for data recovery is returning your flash chip to the developer of the firmware itself as they should know how the firmware operates and can track this history better than anyone else. Of course this depends upon many non-technical factors within the company that developed it. As third party companies likely don't know this IP, it's not likely that they can help much on this front. More likely than not they are just running some simple FAT fix-up utilities as this can probably deal with 50% of the issues out there.
Slashdot Mirror
I agree that local time doesn't matter but for a slightly different reason in addition to the UTC one you gave. You'll notice that many people are saying that they didn't have this issue when others have, only three hours later to say they now have it. I believe that this may be due to the hardware clocks running at different speeds in each system. In *nix systems the software clock normally adjusts for the HW clock differences whenever we reset them. It uses a file with some stats on how much the software clock needed to be adjusted in order to determine how much off of real time the HW clock is running. On system startup it reads the HW clock and this file to determine the time to which to set the software system clock.
For those of us that hit this on 28 Feb I'm guessing our hardware clocks were running fast. Those that took longer to hit it may have had HW clocks that were running slow.
Just realized that the local trophy DBs are likely per-game. Since I didn't access the other game that has trophy data since my last sync that data isn't affected. It's probably only upon accessing the per-game trophy data that it notes it as corrupt and possibly deletes the entries. At least that's my latest guess.
I don't think it has to do with games requiring an active network connection. My system hasn't been connected to the internet (no ethernet cord even plugged in) for over a month and I hit this when starting games that have trophy support.
So, I don't think this has anything to do with an internet connection, just had hardware clock bug that some software modules are barfing on. I think most people first noticed this when trying to connect to PSN, but it's likely the handshaking that's having the issue. However, for me, since I'm not trying to even signing on to PSN it's the trophy registration module is having this issue, which has little to nothing to do with trophy server sync but likely is rather for accessing the local trophy DB. As Sony mentions in their blog, I've lost the latest trophy data from my system (although not all the trophy data since my last server sync). I'm not sure why they seem to have two levels of trophy storage unrelated to server sync though.
You are pretty close on all this. Yes, modern flash firmware should use a reservoir of replacement sectors to fill in for bad ones. Even HDD do this to some degree but I believe limit it to nearby regions. Flash firmware has less of a dependency on location of the bad blocks. It's firmware dependent, so may be limited to sectors in blocks on the same chip when choosing replacement sectors. On most modern firmware there should be no limitation though.
As for write power failure of SSD, modern flash firmware is more transaction based and should recover from this. You may lose the data that was being written at the time of the power failure, but previous data and the firmware datastructures should still be in good shape. However, I'm sure there's still much flash sold on the market that doesn't handle power failures on write; I just hope that they aren't used in SSD's.
Obviously, you can also eventually run out of replacement sectors. At that point it's firmware dependent as to what will happen. Flash cells could start wearing out and being lost at this point as there's nothing to replace it. Even before this point if several flash cells in a sector (or whatever is protected by ECC) fail catastrophically it may be that even ECC can't help the data recovery when writing a replacement sector.
A point that many seem to miss here though is that flash has a history stored in it automatically. Because of the nature of flash, you don't actually write the cell that currently holds the data you want to modify. Instead you actually write a different sector. Due to time and power concerns, the original data will not be erased immediately, but instead at a later point in time. In the meantime the firmware knows to take the more up-to-date version of your data when a read is requested on its logical location.
Hence, in theory, the best chance for data recovery is returning your flash chip to the developer of the firmware itself as they should know how the firmware operates and can track this history better than anyone else. Of course this depends upon many non-technical factors within the company that developed it. As third party companies likely don't know this IP, it's not likely that they can help much on this front. More likely than not they are just running some simple FAT fix-up utilities as this can probably deal with 50% of the issues out there.