You are not logged in.
Pages: 1
I got an OCZ Agility 3 SSD for my Macbook 1,1. I first installed Arch with standard setup, with an ext4 partition, and added discard in /etc/fstab. I then tested whether TRIM support was working (the standard procedure for this seems to be write a test file, look up its position on the disk with hdparm, then delete the file, then read the position to see if it still holds the data), but it was not.
So according to https://wiki.archlinux.org/index.php/SS … _computers, this was because the BIOS was running the disk in IDE mode. So with some effort, I managed to install Arch with grub2-efi, on a GPT partition table, this time with btrfs. Now, AHCI is working, as dmesg.log confirmed. fstab has ssd,discard options set. So now I tested again for TRIM support. I modified my testing method a little, this time searching for my file with hexedit /dev/sda2. It was the output of seq 100000 999999 which is about 6MB in size. I wrote down the address, removed the file, sync'ed, and did sleep 120. Then opened hexedit again and went to the file address. The file was still there, which I thought it should not. hdparm -I output says TRIM supported and deterministic read after TRIM, also the SSD has been updated to latest firmware version.
Did I forget something? Is my testing method wrong?
Last edited by wombat23 (2011-11-10 00:34:32)
Offline
Have you tried this method for testing if TRIM works?
PS: some line breaks would make your post easier to read.
Offline
Thanks for your reply. I'm sorry about the line breaks, must have forgotten.
The difference in the method you linked to is only the size of the test file, right? Because
my file had 6 MB which should be enough to fill at least one single block. I think the problem
is something different:
hdparm -I returns "Deterministic read data after TRIM" (status word 69 bit 14) which is
different from "Deterministic read ZEROs after TRIM" (bit 5). So according to the specification
the drive may have trimmed the data and still return the original data, as long as it doesnt change
the output until next write.
Subtle difference...
Last edited by wombat23 (2011-11-10 22:36:45)
Offline
Maybe you're right, I don't know anything about this deterministic read thing. However when you write "The file was still there" did you check the middle of the file or just the beginning?
Offline
I checked the whole file, else making it 6MB would be pointless. It still held all numbers I wrote into the file.
Well, I had no clue about that deterministic read thing either, so I read up in the ATA specifications, especially in the documents listed here: http://t13.org/Documents/MinutesDefault … yword=trim
Apparently, the standard in its first proposal did not specify the read behaviour of data that has been trimmed and not rewritten, so a disk could return different data for subsequent reads of the same data block, thus becoming "indeterministic", or unpredictable.
Then one year later, Det. Read After TRIM (DRAT) was introduced so that a device could indicate it would always return the same data for a block until next write.
Another 6 months later, another feature called Read Zero After TRIM (RZAT) was introduced. This was for devices to indicate that it would always return 0's for reads on trimmed blocks.
The OCZ drive seems to use only DRAT. What's puzzling me is that the specification does not say what the output would look like for trimmed data. If a read command returns the data originally held, DRAT requires the disk to keep that data and return the exact same thing until next write on that block. The disk cannot overwrite this data or it would become inconsistent.
In other words, the block becomes untrimmed when a read command is issued. I'll try to get a clarification on the OCZ support forums.
Offline
Pages: 1