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!
Before we go any further it is important that you know that this drive is out of interactive support. As you know TRIM is not supported on this drive and in order to optimize the SSD you can use the SSD optimizer found in the SSD Tool Box, here is the link: https://downloadcenter.intel.com/download/18455/Intel-Solid-State-Drive-Toolbox Download Intel® Solid-State Drive Toolbox you are welcome to review the: http://www.intel.com/content/www/us/en/support/software/000006209.html Intel® SSD Toolbox Frequently Asked Questions for Software
You can also use security erase when you deem necessary, just bear in mind that everytime this action is performed the SSD life time is reduced.
Regarding the reserved space, you can set as many partion on the drive as you want if the disk is unallocated.
Thanks for your reply past the end of G1 support.
> As you know TRIM is not supported on this drive and in order to optimize the SSD you can use the SSD optimizer found in the SSD Tool Box
> here is the link: https://downloadcenter.intel.com/download/18455/Intel-Solid-State-Drive-Toolbox Download Intel® Solid-State Drive Toolbox you are welcome to review the: http://www.intel.com/content/www/us/en/support/software/000006209.html Intel® SSD Toolbox Frequently Asked Questions for Software
Q&A # 2 in that doc says SSD Optimizer doesn't work on 50nm (G1) SSDs. I suppose it has something to do with the lack of TRIM support, which SSD Optimizer probably needs do to its job.
> You can also use security erase when you deem necessary, just bear in mind that everytime this action is performed the SSD life time is reduced.
May I have an approx lifetime reduction figure? (say, in % of SSD's lifetime upon every Secure Erase) That'll tell me how often I want to run it.
> Regarding the reserved space, you can set as many partion on the drive as you want if the disk is unallocated.
Sorry unsure I got the idea... what I'm after is whether overprovisioning my 160GB SSD, i.e. reducing its capacity available for user data down to 80-120GB by means of SET MAX ADDRESS ATA command or just leaving the rest of it unpartitioned is any better (i.e. will increase its life and/or performance) than running with entire capacity allocated to its partition(s)? Or G1's SSD controller will level its wear regardless, making overprovisioning unnecessary?
- the following Intel whitepapers on Overprovisioning suggest (if I got it right) that reducing usable space from 160GB to 96GB increases SSD's endurance from 29TB to 150TB:
http://cache-www.intel.com/cd/00/00/45/95/459555_459555.pdf http://cache-www.intel.com/cd/00/00/45/95/459555_459555.pdf <<< Currently unavailable; I guess it's Intel whitepaper doc # 324441-001 or 324441-002:</a>
- here an Intel X25-M G2 80GB SSD overprovisioning as 64GB is expected to deliver almost 4x life and performance boost based on the aforementioned Intel whitepaper(s):
If these Intel overprovisioning guidelines apply in particular to G1 SSDs I'll be more than happy to overprovision them with up to 50% reserve to make them last "forever" )
P.S. Btw we could probably treat my questions on Secure Erase impact and Overprovisioning benefits as equally applicable to G2 and all newer SSDs.
I don't see that it support SET MAX ADDRESS according to smartctl/hdparm identifying my 80GB G1. You can at most leave certain amount of space unpartitioned and HOPE that the controller would make good use of it
I wonder what's the point to do secure erase here if it is expected to reduce life span. I have always used it to wipe my G1 since the day I found out such thing. Not trying to lengthen its life span but just because its quick and convenient. Still living alright with more than 9TB Host Write and frequent secure erase.
FWIW, G1 could be the most durable Intel SSD series ever made. I remember reading some data showing how exceptional it is when compared with the "modern" series from Intel and other vendors.
Thanks for your reply. May I ask how often you do SE on yours? I had to do it only once so far - after my spouse said her PC is "slowish". The figures in my OP suggest it boosted the speed a lot (in fact even higher than brand-new somehow!), so I definitely don't mind doing SE more often (well, at least once every half a year) and ideally would like to understand exactly how much resource each SE costs the SSD. Hopefully this figure isn't confidential and we'll get an Intel rep to disclose it.
> FWIW, G1 could be the most durable Intel SSD series ever made. I remember reading some data showing how exceptional it is when compared with the "modern" series from Intel and other vendors.
Well, being infinitely far from internal SSD design I suppose it has something to do with stuffing "just" 4 voltage levels into those large 50nm cells: there's no such luxury anymore with modern ones. Planar TLC ones e.g. Samsung 840 EVO are definitely a no-go because of the well-known old data read degradation issue, and we have yet to see what newer V-NAND TLC ones such as 850 EVO are like.
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.
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.
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.
> 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."
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.
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:
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.
In fact X25-M G1/G2 specs, unlike the 530 and 1500 specs you're referring to, even have no SECURITY ERASE UNIT breakdown into these:
- Normal Mode – Full NAND erase of user available space and spare area
- Enhanced Mode – Cryptographically erase data
Security Mode Feature Set (albeit optional) with SECURITY ERASE UNIT command reportedly dates back to ATA-2 (cannot see anything like that in ATA-2 myself though) while its implementation is only specified starting with ATA-4:
http://www.fatwallet.com/forums/technology/1061788/m15883621/# m15883621 Need to wipe all data from my HD. Want to make sure this is correct. - Displaying message 15883621
So perhaps Intel can claim that (E)SE implementation in their non-Pro SSDs is still ATA compliant implying ATA-2 where its implementation is effectively left up to the vendor?..
I know right, because "Cryptographically erase data" only apply to those with "AES 256-bit Encryption" (non-OPAL one; and maybe some models do 128-bit, idk). It's essentially regeneration of the encryption key.
And that's why I think that SE and ESE are equivalent in SSDs that do not do encryption at all (e.g. X25-M). To some extent I think vendors should simply declare in such drive that ESE is not supported, and I've seen such SSD from another vendor.
Honestly, who cares if it's completely ATA compliant. It matters more whether the implementations make sense / are useful to the drive. For example, although ESE is supposed to be "vendor-specifc", but that is only about the pattern being used to to fill the drive. As of ATA-8 ACS-3, neither of them should do anything else other than filling. In that case, if those drives which support encryption are made "ATA compliant", there wouldn't be nice feature as "Cryptographically erase data".