Дай угадаю: ты отключил журнал?

Либо ядро очень древнее, TRIM не так давно запилили в ext4 (по дебиановским меркам)

swap, /var/log/, /tmp/ вынесены на HDD.

Зачем? У тебя контролер SSD навернется намного быстрее износа ячеек. OCZ и так рекордсмены по ненадежности, а твоя модель тем более.

ps: бывший владелец vertex 4, который начал глючить через полгода.

На HDD должны быть только фильмы, музыка, iso и подобные файлы. SSD нужно или использовать, или не покупать. Кстати, noatime включает в себя nodiratime, достаточно noatime.

Нет, включен как ordered

3.2 ядро, trim держит

С какого лешого он быстрее умрет? Наоборот я уменьшил запись на SSD. Как это на контроллер то влияет?

Может быть все работает, судя по вики http://en.wikipedia.org/wiki/Trim_(computing) совсем не обязательно чтобы пустые ячейки после трима возвращали нули.

...
Deterministic Trim (DRAT): all read commands to the LBA after a Trim shall return the same data, or become determinate. (SATA Word 69 bit 14)
...

Вот именно, что может, хотелось бы быть уверенным на 100%.

Ocz умирают просто так, независимо от нагрузки.

В крайнем случае можно делать что-то вроде:

ionice -c 3 fstrim -v /

В какую переодичность? fstrim -v / вроде работает, выплевывает колво байтов.

А что не так с ними? Производитель 5 лет гарантии дает.

Следует ли прошивку обновить или сдохнет?

Зависит от интенсивности записи и количества свободного места, грубо говоря [свободное место]/[сколько пишем в день] = [интервал меду тримами], так что раза в день должно быть вполне достаточно.

Просто ты занимаешься ерундой, и переживаешь за то, что не сломается. У меня тоже 5 лет гарантии, вот надо собраться и отнести этот кусок гомна. Этак сколько у меня писалось на него - хватило бы на 7 лет, а толку, если накрылся контролер? Олсо фирма ocz rip, если ты из криокамеры.

Сделай трим по крону раз в сутки, а все остальное — ерунда. Ну и важные данные в эксклюзивном варианте на нем не храни.

«lsblk -D» что говорит ?

lsblk -D

NAME   DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda           0      512B       2G         0
├─sda1        0      512B       2G         0
└─sda2        0      512B       2G         0
sdb           0        0B       0B         0
├─sdb1        0        0B       0B         0
├─sdb2        0        0B       0B         0
├─sdb3        0        0B       0B         0
├─sdb5        0        0B       0B         0
├─sdb6        0        0B       0B         0
├─sdb7        0        0B       0B         0
├─sdb8        0        0B       0B         0
└─sdb9        0        0B       0B         0

нет 0B у SSD, это значит, что TRIM пашет? но походу не в автоматическом режиме....

на sda trim будет работать, на sdb - нет.

а в каком режиме:? в автоматическом или стоит fstrim -v / в крон запихать?

и почему Data Set Management TRIM supported (limit unknown)?

Я fstrim по хрону запускаю

Data Set Management TRIM supported (limit unknown)

Не знаю.

Для INTEL SSDSC2CW120A3 оно 1 блок

Для OCZ-VERTEX4 оно 16 блоков

А этот тест мало что значит. Во-первых, не уверен в правильности методики (имхо, записываемые данные должны точно лечь на erase блок). Во-вторых, контроллер может запросто проигнорировать trim, если, например, посчитает, что свободного места и так достаточно. Или отложит «напотом».

В ocz вообще говорят, что trim для bigfoot контроллера необязателен из-за навороченного gc.

На моё имхо, параметры монтирования переусложнены. Вполне достаточно defaults,relatime,discard.

Диск хороший :)

Пока единственное нормальное решение, тема закрыта.

$ cat /etc/cron.daily/fstrim

#!/bin/sh
# TRIM for SSD
LOG=/var/log/fstrim.log
MOUNT_POINT=/
/bin/echo `date` >> $LOG
/usr/bin/time -a -f "real: %E, user: %U, sys: %S" -o $LOG /usr/bin/ionice -c 3 /sbin/fstrim -v $MOUNT_POINT >> $LOG
/bin/echo >> $LOG