I don't have personal experience with those SSD models, but to my understanding you are right (i.e. you cannot use secure erase).
OTOH the secure erase ATA funtion mainly serves the purpose to safely wipe the whole drive (incl. cache area) from data. The so-called 'cell-clearing' for SSDs is just a side effect, as I understand it. The ATA security commands existed in HDDs before there were SSDs and particularly the early SSD models all had big curves to get the firmware right. Some vendors offered DOS tools (as mentioned in the article too). Maybe you find something like that with asus (I would not bet on it).
The link you post has good explanations, but those drives were all different and it is pretty difficult to measure such a degradation in performance in a consistent way (.. and they don't explain how they produced those catastrophic throughputs for the article). If you did not notice severe degrading performance (which must be attributed to the drive), I would not worry about that. Just dd the SDD with /dev/zero when you plan to re-install and be happy that it is faster than any Hdds that fits the machine anyway. And use trim of course, if it supports that + the wiki tricks for relatime etc.
Makes sense to me. I've given up on a hardware reset and just reformatted, my partitions weren't aligned to the erase blocks so I fixed that. A basic dd write test completes around 50% faster which I'm quite satisfied with! This will hopefully translate into a noticeable speed boost after all the wiki SSD optimisations.
Cheers.
]]>OTOH the secure erase ATA funtion mainly serves the purpose to safely wipe the whole drive (incl. cache area) from data. The so-called 'cell-clearing' for SSDs is just a side effect, as I understand it. The ATA security commands existed in HDDs before there were SSDs and particularly the early SSD models all had big curves to get the firmware right. Some vendors offered DOS tools (as mentioned in the article too). Maybe you find something like that with asus (I would not bet on it).
The link you post has good explanations, but those drives were all different and it is pretty difficult to measure such a degradation in performance in a consistent way (.. and they don't explain how they produced those catastrophic throughputs for the article). If you did not notice severe degrading performance (which must be attributed to the drive), I would not worry about that. Just dd the SDD with /dev/zero when you plan to re-install and be happy that it is faster than any Hdds that fits the machine anyway. And use trim of course, if it supports that + the wiki tricks for relatime etc.
]]>Hi, jbrind, and welcome to Arch Linux forums :0(
When pasting configs, code or command output, please use [ code ] tags https://bbs.archlinux.org/help.php#bbcode
like this
It makes the code more readable and - in case of longer listings - more convenient to scroll through.
Googling 'ERASE_PREPARE: Input/output error' didn't help much, I found https://github.com/marktheunissen/wiki/wiki/Intel-ssd and http://forums.partedmagic.com/viewtopic … f&start=10 - no solutions.
In the marktheunissen wiki the author wrote that executing security erase without setting a password result in the error you get:
Some variations of this method are spread on various internet sites, but they will not work because security is “not enabled”, when issuing the hdparm command:
sudo hdparm --user-master u --security-erase NULL /dev/sda
As you can see, this results to the following output/error:
security_password=""
/dev/sda: Issuing SECURITY_ERASE command, password="", user=user ERASE_PREPARE: Input/output error
Maybe it's too short, maybe it's just a coincidence that you get this error - I don't know.
Thanks for your reply. I didn't remember code tags existed - I've fixed that.
I've tried setting various lengths of password as well as 'NULL' but no joy.
The link below suggests that old SSDs such as the one in the EeePC 900, a similar model to mine, do not support this ATA command at all. As far as I'm aware the same SSD is used in both, should I give up hope in restoring my factory write speeds? As I understand it the reset must be performed at the hardware level to accomplish this.
]]>When pasting configs, code or command output, please use [ code ] tags https://bbs.archlinux.org/help.php#bbcode
like this
It makes the code more readable and - in case of longer listings - more convenient to scroll through.
Googling 'ERASE_PREPARE: Input/output error' didn't help much, I found https://github.com/marktheunissen/wiki/wiki/Intel-ssd and http://forums.partedmagic.com/viewtopic … f&start=10 - no solutions.
In the marktheunissen wiki the author wrote that executing security erase without setting a password result in the error you get:
Some variations of this method are spread on various internet sites, but they will not work because security is “not enabled”, when issuing the hdparm command:
sudo hdparm --user-master u --security-erase NULL /dev/sda
As you can see, this results to the following output/error:
security_password=""
/dev/sda: Issuing SECURITY_ERASE command, password="", user=user ERASE_PREPARE: Input/output error
Maybe it's too short, maybe it's just a coincidence that you get this error - I don't know.
]]>After several years of use I thought the SSD in my Asus EeePC 1000 could benefit from a cell reset as described below:
https://wiki.archlinux.org/index.php/SS … l_Clearing
https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase
I ran the following commands using a recent copy of Arch off a USB stick.
# hdparm -V
hdparm v9.43
# hdparm -iI /dev/sda
/dev/sda:
Model=ASUS-PHISON SSD, FwRev=TST2.04U, SerialNo=SOQ1881040
Config={ HardSect NotMFM Fixed DTR>10Mbs }
RawCHS=15636/16/63, TrkSize=32256, SectSize=512, ECCbytes=4
BuffType=DualPort, BuffSize=1kB, MaxMultSect=1, MultSect=off
CurCHS=15636/16/63, CurSects=15761088, LBA=yes, LBAsects=15761088
IORDY=yes, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 *udma4
AdvancedPM=no
Drive conforms to: Unspecified: ATA/ATAPI-4,5
* signifies the current active mode
CompactFlash ATA device
Model Number: ASUS-PHISON SSD
Serial Number: SOQ1881040
Firmware Revision: TST2.04U
Standards:
Supported: 5 4
Likely used: 6
Configuration:
Logical max current
cylinders 15636 15636
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 15761088
LBA user addressable sectors: 15761088
Logical/Physical Sector size: 512 bytes
device size with M = 1024*1024: 7695 MBytes
device size with M = 1000*1000: 8069 MBytes (8 GB)
cache/buffer size = 1 KBytes (type=DualPort)
Capabilities:
LBA, IORDY(cannot be disabled)
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 1 Current = 0
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* Power Management feature set
* WRITE_BUFFER command
* READ_BUFFER command
* NOP cmd
* CFA feature set
* Mandatory FLUSH_CACHE
* CFA advanced modes: pio5 pio6 mdma3 mdma4
Integrity word not set (found 0x0000, expected 0x15a5)
No 'Security' information is displayed, only an 'Integrity word not set' error. When I proceed to set a password and erase as per the instructions, the commands fail with an input/output error:
# hdparm --user-master u --security-set-pass pw /dev/sda
security_password="pw"
/dev/sda:
Issuing SECURITY_SET_PASS command, password="pw", user=user, mode=high
SECURITY_SET_PASS: Input/output error
# hdparm --user-master u --security-erase pw /dev/sda
security_password="pw"
/dev/sda:
Issuing SECURITY_ERASE command, password="pw", user=user
ERASE_PREPARE: Input/output error
At least one person has the exact same problem:
http://forums.gentoo.org/viewtopic-t-84 … art-0.html
Is this a limitation of my SSD? I'd appreciate any advice on workarounds.
Thanks.
]]>