SandForce "SF-22XX" issues and workarounds

[Christopher]

I knew you were not testing it, but I didn't know you had two SF2281s in one rig. I think idling is the opposite extreme of the endurance test anyway for SF2. On my system, I've been writing about .7 to 1.2 GB a day on the system drive. I was using my Intel X25-E, but cloned that to my Vertex Turbo 128.

Incidentally, I've been wondering about SF 1 and 2. Since they don't have DRAM caches, they use nand on the drive. Maybe SFs aren't limited by the NAND endurance overall, but perhaps they keep wearing out the same NAND device from storing all the associated SF data. If it didn't adequately rotate where it stored all the data necessary to make SF work, maybe writing millions of files is more detrimental than just writes to NAND.

[sergiu]

Incidentally, I've been wondering about SF 1 and 2. Since they don't have DRAM caches, they use nand on the drive. Maybe SFs aren't limited by the NAND endurance overall, but perhaps they keep wearing out the same NAND device from storing all the associated SF data. If it didn't adequately rotate where it stored all the data necessary to make SF work, maybe writing millions of files is more detrimental than just writes to NAND.

I guess SF data is specific to a number of pages (like keeping parity data for 8 pages in a separate and complete page) so it should not matter too much the number of files. Also, most probably pages are grouped so writing pattern should also not impact the usage. Sandforce advertise the fact that internal data is spread thru all dies for better redundancy. It might be very sad to find out that this is not true

[Christopher]

For a SSD, it should be no difference other than WA between writing one file and writing one million, as writing file system metadata is still just a write request, just like any other. It would be possible for a SSD to "know" about OS filesystem but that would be "suicide" as that model would be tied to a specific file system and thus to a specific family of OSes.

The SF has to keep tables of information and I guess hash data, that gets written in conjunction with NAND writes. If it writes this info to the same area without rotating it, couldn't it wear out that nand from constant writing since it's not keeping this info in flash? Maybe I'm grossly overestimating the amount of data this is, but if it's always writing this information to the same physical nand device, maybe it could put disproportional wear on one nand device vs. the others - forget the file system, but maybe this data is a different amount based on the compressibility of the written data, or something. Maybe it's different for smaller capacity drives that don't have a whole die's worth of nand sacrificed.

I'm not really smart enough to know much about that, but I wonder if SF drives might have additional reasons to not wear in the same fashion as non-SF controlled drives. So far, wear to non-SF drives has been pretty linear. Perhaps there is something else going on behind the scenes with SF that would make them not wear out in the same linear manner.

[sergiu]

There are a lot of possible variations, indeed. Another thing is that we do not know for sure different internal details. We can only guess based on behavior but we might be far from truth. Now either way, the overhead cannot be so high to seriously impact the wear. At zero fill for example, it has a compression rate of ~13% and what I always assumed is that a big part of these percents are actually the overhead.

[johnw]

Incidentally, I've been wondering about SF 1 and 2. Since they don't have DRAM caches, they use nand on the drive.

I don't think that is true. They may not cache host data in DRAM, but I think that they keep some metadata in DRAM. That is similar to how the Intel 320 SSDs work -- they also do not cache host data, but they do have a small DRAM for holding metadata.

By the way, remember that some of the higher end Sandforce SSDs have/had a supercapacitor for backup power. There would be little reason for a supercapacitor if there was no information stored in volatile memory.

[Christopher]

I don't think that is true. They may not cache host data in DRAM, but I think that they keep some metadata in DRAM. That is similar to how the Intel 320 SSDs work -- they also do not cache host data, but they do have a small DRAM for holding metadata.

By the way, remember that some of the higher end Sandforce SSDs have/had a supercapacitor for backup power. There would be little reason for a supercapacitor if there was no information stored in volatile memory.

That's a very good point.

With a 120GB Toggle Nand equipped 2281 you will end up with 111GB, with almost 17GB worth of over provisioning and one die given up for the RAISE scheme (and supposedly other SF related needs). It is said that the SF processor has some internal cache, but probably not very much, so who knows?

I'm way more excited by almost hitting the 60hr mark with the Mushkin. If I can hit 75 or 100 hours I'm going to "undo" the changes I've made, and see if I go back to having crashes every 30 hours (or earlier if I want... I can get it to happen whenever I want, so long as I only want it to happen within 12 hours with MSAHCI, but there's no magic switch to make it happen immediately). 30hrs is with latest official Intel RST drivers for both 1155 motherboards and I have another one on the way to test with as well.