X25-M G1 usage guidelines

[DAndr17]

Hi All,

Bearing in mind that X25-M G1 SSDs do not support TRIM are there any particular guidelines from Intel on how to best use these SSDs to make the most out of them? For instance if I know in advance that I'll fit into 60GB should I set reserve in my 160GB ones at half their capacity for 75% occupancy (60/80) or rather leave it intact for 37.5% occupancy (60/160)? Also how often should I do Enhanced Secure Erase on them to bring their speed closer to that of their G2 counterpart and how will it affect their lifetime in figures? E.g. ESE done on one of my X25-M G1 80GB SSDs after about a year of light usage in a SATA-I capped ThinkPad X60s appears to be quite helpful, so I wound't mind doing it more often other things equal:

Thanks in advance!

[TYan3]

It depends. Could be as frequent as once a week or so, because for some reason I very often want it wiped clean.

I always wonder what Secure Erase IS in G1. As you may already know, in traditional HDDs it usually means zero or pattern filled, which would not be what G1 do because it can't be that quick. But at the same time G1 does not appear to have any sort of AES encryption, so it can't be regeneration of key like the Enhanced Secure Erase in the 530 series or so. So it seems to me it can be only some sort of equivalence to a full device TRIM. So I suppose it cost more or less the same as full device TRIM in general SSDs these days.

P.S. And I think Secure Erase and Enhanced Secure Erase is equivalent in G1.

[DAndr17]

After reading a few user reports about speed drop following (standard) SE I tried digging into the subject and ended up doing ESE (using HDDErase) hoping for device specific "idle" byte to be written instead of 00 or some other predefined value written with SE and still regarded by SSD as occupied. Whether G1 SSDs support it or not I didn't check thinking it's an inherent feature of any SSD - but judging by the speeds that bounced back to high values that appears to have succeeded somehow. If the impact of ESE on G1 is equivalent to that of its full TRIM we can use ESE as healthy compensation for the lack of TRIM support, as you already do. What I find strange is no comments whatsoever from Intel on how to best use G1 to make it as durable as G2 covering at least (E)SE and OP: even their white papers on OP can no longer be downloaded from their website for some reason.

Btw dividing 80GB by 67MB/s (max sequential write speed) I get something close 20min to write my entire G1 SSD. My ESE was nowhere near that, taking something like a minute or even less. However I read somewhere that being an internal ATA command, (E)SE works much faster than a regular write. It'd be extremely interesting to obtain the details of (E)SE operation in Intel SSDs, incl G1 ones.

[TYan3]

I always do (E)SE with hdparm in Linux. I never noticed any difference (their own speed / the write speed they "produce") between the two on the G1.

I don't think it's really strange though, because I never saw any vendors stating really clearly what (E)SE does on their drives. It more or less involves users' speculations / deduction anyway.

I am pretty sure neither of them are zero filling in G1 though, coz in HDDs where SE is zero filling, it takes more or less as long as wiping with "dd" or so. Whether it's "internal ATA command" does not matter. (It doesn't really make sense anyway, simple write commands are at the end "internal ATA command" too...)

Btw I never bothered to do "overprovisioning" myself, partly because I don't see any way to confirm that the controller would really make use of it. And I wonder for those which do, do they work on both MBR and GPT? Coz if they use unpartitioned blocks for OP, I suppose they'll need to able to parse the partition table. If the controller does not recognise GPT properly but only parse the protective MBR, it will probably consider the whole drive is partitioned anyway.

[DAndr17]

> I never saw any vendors stating really clearly what (E)SE does on their drives.

Unfortunately looks like Intel in particular is carefully ignoring it too, e.g. here:

But from this:

"Secure Erase is supported on all Intel SSD Professional Family products, including the Intel® Solid-State Drive Professional 1500 Series."

http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/ssd-pro-1500-secure-erase-p... http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/ssd-pro-1500-secure-erase-p...

we might infer that SE is not supported in non-Pro SSDs, meaning no actual 00 or any other value is ever written anywhere during its execution, effectively violating the ATA spec, which tells not just what to do but exactly how to do that:

"The current ATA specification for Normal Erase mode states that the SECURITY ERASE UNIT command shall write binary zeroes to all user accessible data areas."

Not writing anything is actually better for me due to less impact on its life (fortunately I needn't care about data security): my main interest is the "TRIM" aspect of (E)SE. Just found the following in my old notes although unsure where it comes from:

"Standard disk erasure tools write to every block on the disk, which makes the SSD controller think that every single block contains useful data and must be moved for wear leveling. The ATA Secure Erase command, in contrast, tells the SSD controller that the entire drive contains no useful data, so the wear leveling mechanism resets to factory condition (and eliminates common SSD problems such as internal fragmentation)."

In that case SE implementation may be similar to file deletion in DOS/Windows - it's no true erase at all really, at least from the ATA spec compliance perspective: all it seems to do is tells the SSD controller to mark all pages as free, hence TRIM-like side effect.

...Intel, please: G1 SSDs are 5 years old by now, why still keep it in secret (except just for legal reasons I imagine). No need to reveal whether (E)SE actually writes anything into the SSD: we do realize that it most likely doesn't ) Just stating the impact of a single ESE on G1 SSD life would be good enough for me to plan its optimal handling.

[TYan3]

I doubt that ANY SSD would "conform" with ATA spec when implement normal erase mode (which is either 0/1 filled: http://www.t13.org/Documents/UploadedDocuments/docs2013/d2161r5-ATAATAPI_Command_Set_-_3.pdf http://www.t13.org/Documents/UploadedDocuments/docs2013/d2161r5-ATAATAPI_Command_Set_-_3.pdf), coz it probably doesn't make much sense in flash memory.

And (E)SE in the pro series doesn't have anything special, except when the OPAL thing is activated:

https://en.wikipedia.org/wiki/Opal_Storage_Specification Opal Storage Specification - Wikipedia, the free encyclopedia

Compare the descriptions about (E)SE in these two:

http://www.intel.com/content/dam/www/public/us/en/documents/product-specifications/ssd-530-sata-spec... http://www.intel.com/content/dam/www/public/us/en/documents/product-specifications/ssd-530-sata-spec...

http://www.intel.com/content/dam/www/public/us/en/documents/product-specifications/ssd-pro-1500-seri... http://www.intel.com/content/dam/www/public/us/en/documents/product-specifications/ssd-pro-1500-seri...…

When OPAL is activated, the SECURITY FEATURE SET is simply disabled (so out of the scope of our discussion).

I do wonder whether normal erase mode in them are strictly equivalent to full device TRIM though. I don't think that is a question for only X25-M G1, but all SSDs from Intel or other vendors in general.