You are not logged in.
Pages: 1
Today, after a long time, I have decided to run TRIM manually. I have been surpried, that it has trimmed exactly all the unused space on the partition. On the second run, it expectedly reported 0.
[rok@rok-laptop ~]$ sudo fstrim -v /
/: 20,9 GiB (22452695040 bytes) trimmed
[rok@rok-laptop ~]$ sudo fstrim -v /
/: 0 B (0 bytes) trimmed
Here is my /etc/fstab
[rok@rok-laptop ~]$ cat /etc/fstab
#
# /etc/fstab: static file system information
#
# <file system> <dir> <type> <options> <dump> <pass>
tmpfs /tmp tmpfs nodev,nosuid 0 0
/dev/sda1 / ext4 discard,relatime 0 1
/dev/sda2 none swap discard,defaults 0 0
Offline
I noticed same behaving:
dan@530uarch ~ $ sudo fstrim -v /
/: 8 GB (8589934592 bytes) trimmed
dan@530uarch ~ $ sudo fstrim -v /
/: 0 B (0 bytes) trimmed
dan@530uarch ~ $ cat /etc/fstab
#
# /etc/fstab: static file system information
#
# <file system> <dir> <type> <options> <dump> <pass>
# /dev/sda1
UUID=49f66c2c-5bd3-4843-bd24-714dc1c0d188 / ext4 rw,noatime,commit=15,data=ordered,discard 0 1
# /dev/sda5
UUID=1166c42d-d01a-40bf-8926-2795b3f0b834 /home ext4 rw,noatime,commit=15,data=ordered,discard 0 2
# /dev/sda3
UUID=C332-535C /run/media/dan/shard vfat rw,user,umask=022,uid=1000,iocharset=utf8,noatime 0 0
There was actual test to see if trim really works (you saw zeros on trimmed blocks). I will try it tomorow (hopefully)
Last edited by Kotrfa (2013-05-13 22:16:08)
Offline
I have made that test twice in the past, failed both time.
Offline
Try this instead... http://nedoboi.wordpress.com/2011/11/12 … -it-works/
It is probably a much better indicator of whether trim is working or not, as it is actually looking at the bits on the disk to see if they are returned to 0 after file delete.
Offline
That is what I was thinking about. Trim obviously doesn't work:
dan@530uarch ~ $ sudo hdparm -I /dev/sda|grep -i trim
* Data Set Management TRIM supported (limit 8 blocks)
dan@530uarch ~ $ sudo hdparm --fibmap testfile.txt
[sudo] password for dan:
testfile.txt:
filesystem blocksize 4096, begins at LBA 48821598; assuming 512 byte sectors.
byte_offset begin_LBA end_LBA sectors
0 78456014 78456021 8
dan@530uarch ~ $ sudo hdparm --read-sector 78456014 /dev/sda
/dev/sda:
reading sector 78456014: succeeded
3031 3030 2031 6574 7473 6c20 6e69 0a65
...
3031 3330 2032 6574 7473 6c20 6e69 0a65
dan@530uarch ~ $ rm testfile.txt
dan@530uarch ~ $ sync
dan@530uarch ~ $ sudo hdparm --read-sector 78456014 /dev/sda
/dev/sda:
reading sector 78456014: succeeded
3031 3030 2031 6574 7473 6c20 6e69 0a65
...
3031 3330 2032 6574 7473 6c20 6e69 0a65
dan@530uarch ~ $ sudo fstrim -v /
/: 8 GiB (8532078592 bytes) trimmed
dan@530uarch ~ $ sudo hdparm --read-sector 78456014 /dev/sda
/dev/sda:
reading sector 78456014: succeeded
3031 3030 2031 6574 7473 6c20 6e69 0a65
...
3031 3330 2032 6574 7473 6c20 6e69 0a65
Anyone has idea why and how to turn it on?
Edit:
I displayed sectors few minutes after and it shows some random data. Shouldnt be there only zeros?
sudo hdparm --read-sector 78456014 /dev/sda
/dev/sda:
reading sector 78456014: succeeded
0af0 446d 596f 5478 4ca6 f26b 8f99 c94b
fc84 6edd 47be 8ff1 9ee9 f472 5d2c 97be
dfc7 75dd 60bf 7f7e fe83 1a82 0685 c8c6
fcff c0e8 b56b 9061 1260 806b c340 c170
63a4 11f2 0883 b85a 156f e5a1 0763 58af
9982 dd22 1146 715e c0a2 3ce8 2f19 4205
a25c dfaf 8367 4221 c3b8 2f4a c314 08bf
c30d 630f efe8 408b cecc f8d3 ca6e 74cc
ec93 74fb bf3e 7f04 16f3 882e 7aeb 7250
ca78 727d 76f9 e816 6fcb 263f 2d51 ef36
a1ac 0375 a32d c837 3be3 2e0c f785 2468
2bcf 3611 71bf 262d e59d c6bd 171d 63c3
f09f 3c6b 88d1 041a 0399 9f7f 6caa e3dc
1e27 8732 af8f b466 413b c378 9a65 daf7
c860 788f 7443 43e2 58bf 7d5c 5eac 4fa6
051e bd60 c109 32b1 3d88 9f46 f6ac 1728
908b 7786 87f2 696b f5dc 9beb c9f0 4095
59d8 f5f0 c748 80bc 2336 484f 911d a14d
fda7 d641 9169 292f 2f26 863e 3e31 da8d
a95d 94ad 386a ad4e c3d4 2978 1de2 c29c
0a61 e27e a944 7546 e5c4 325e 220f af8e
ea36 c711 17e1 ef1c 44e2 03af 0ebf c4c3
0438 f40d cc21 09d0 d3d3 2508 757c 7a28
9337 4ad8 7e0f 2127 8862 161f 7b8e 32a4
f0f2 0e23 841f 70cf 423b dc6f c3a4 a2d7
e0c4 9823 1bc7 e375 927f 3dc0 fc2a 77ef
4df1 121f efdb ec8a 23b0 648a f457 aec8
a607 0f5d f79b 7c24 4846 79bd b3d7 bea9
2f84 3e7b edbb 372f e124 5cb3 07cf 3d4f
7a89 e3ea 023d 1fe6 a874 49a7 7c47 109a
361e a425 b2d1 6387 feb3 e612 5af7 0f54
ad6f af09 80b6 5dad efc0 bff0 20b6 d1fc
It just doesn't work. When I run twice:
dan@530uarch ~ $ sudo fstrim -v /
/: 8 GiB (8535908352 bytes) trimmed
dan@530uarch ~ $ sudo fstrim -v /
/: 0 B (0 bytes) trimmed
then reboot computer and run this sequence again, it shows the same outputs (8 GB trimmed...).
By the way, assuming that "Trim check" utility does work in Win7 , TRIM does works there also.
Last edited by Kotrfa (2013-05-15 07:28:38)
Offline
Can please anyone with SSD do this test and post his configuration? Thanks a lot
Offline
If I'm not wrong, the data returned from a sector after it has been trimmed is not defined to be all zeros, it could be all zeros, garbage or the data present on the sector before trim. I think I've read this somewhere, just don't remember where.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
@R00KIE, so you're saying that it will try to batch up TRIM functions anyway? When I last tested, I got a significantly slower rate of file removal with the discard flag then without.
@OP, if this is the case, then it might make a difference if you try the test again. But this time before you do the final check of the actual raw disk contents, do a "sync" first. If what R00KIE is saying is true, then theoretically what you saw there is of no consequence. There is the possibility though that the TRIM function is not held under teh same umbrella as normal write operations. SO what I mean by that is that there is a chance that the sync command might not actually also discard the unsused blocks with it. That might be a pure function of the SSD's own garbage collection mechanisms.
Offline
I recall reading this somewhere else but it seems wikipedia as something about this too [1]. If I had to guess I'd say most SSDs use non deterministic trim since I suppose that is the easiest to implement.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
From that wikipedia page R00KIE linked to above, it lead me to the sata-io page about SATA III 6Gb/s. In it there is a part about SATA 3.1 implementing a "Queued Trim Command" which reads:
Queued Trim Command – allows SATA SSDs to execute Trim without impacting normal operation, improving SSD performance
So it may be that your system is indeed simply functioning correctly, as the page I linked to was written just months after the 3.1 spec was released, so these features were probably not implemented in much hardware at the time.
Offline
My interface is just SATA 2.
I have performed the test, but the data doesn't get nulled out. What is even worse, the data is not 0, even when i run fstrim explicitly. Take a look:
Offline
Did you check the output of 'hdparm -I /dev/sda | grep -i trim' like charti showed in the printscreen? If you did, what is the output? Which brand, model SSD do you have and which firmware version does it have?
Maybe someone else with a similar ssd can test and check if the results are the same or maybe someone will spot something wrong.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
You know, I actually just took my own advice and tried this for myself. It would seem that it is indeed not trimming the disk.... I'm honestly not very concerned, but I was just really curious. I created a ext4 filesystem on my Mushkin Atlas mSATA 128GB SSD, and then tested there. I have btrfs as my primary system, and it does not seem to work there (I mean the hdparm's ability to find the sector of a file, etc.).
Offline
ATA device, with non-removable media
Model Number: SAMSUNG SSD 830 Series
Serial Number: S0WJNYAC102862
Firmware Revision: CXM03B1Q
[rok@rok-laptop baza]$ sudo hdparm -I /dev/sda | grep -i trim
* Data Set Management TRIM supported (limit 8 blocks)
Offline
So it seems your SSD doesn't report "Deterministic read ZEROS after TRIM" as the one charti owns, so I would say the ssd knows that the sector is not used anymore and the information there doesn't need to be preserved, it's just that it will garbage collect it when it deems necessary/needed (or after a while or during idle time) and the read will return whatever is there, which takes is back to what is stated in the wikipedia I linked before:
Non-deterministic TRIM: each read command to the LBA after a TRIM may return different data. (SATA Word 169 bit 0)
I just don't know what hdparm reports in this case, maybe nothing as it seems to be the case. I guess you can always email samsung and ask, maybe you get lucky and they will answer you.
On another note, if your ssd after a trim reports the previous sector data it is actually good for full disk encryption as a potential attacker can't gather information from which sectors are trimmed as the disk/fs gets used.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
Pages: 1