> И кстати erase - это весьма длительная операция.

Как то раз один дурак ляпнул и теперь все заучили как молитву.
Это из раздела - переходные процессы длятся бесконечно долго :-)))
Без тестов больше эту херню тут не пишите.

>[оверквотинг удален]
> Вполне себе верна. Чем больше пространства для маневра - тем реже приходится
> судорожно дергаться на каждый пшик и тем лучше можно соптимизировать операции.
> Собственно грубый прототип того что получается ты и так увидел на
> забитом под завязку томе. А тут похожая логика: размазывание записи -
> по сути вариант CoW получается. Ну и общие свойства стало быть
> похожи. Как ты понимаешь, закладывать большой маневровый запас всем обломно: его
> не видно в емкости накопителя которая написана на упаковке, а вот
> место в чипах памяти оно жрет. Производителю не нравится напаивать больше
> памяти при том что цифра на упаковке не увеличивается. Ведь хомячки
> покупают гигабайты :)

Еще производитель старается подгадать срок эксплуотации под гарантийный ...

> В этом случае как раз контроллер имеет все шансы заранее сгрести мусор.
> Тогда стирания не будет, только программирование страниц. И чем больше места
> не занято - тем больше пространства для маневра: может получиться воткнуть
> желаемую запись куда-то в уже очищенные страницы. А если trim нет
> то постепенно все придет к схеме когда "проблема решается по мере
> возникновения" - т.е. при вообще каждой записи надо чистить какой-то блок
> чтобы оформить запись. Заранее почистить нельзя т.к. неизвестно что используется а
> что нет. По поводу чего и скорость записи просядет, и возможности
> оптимизации размещения записей у контроллера будут откушены по полной программе.

Многие люди суют ssd в рейды встроенные в матери, и большая половина этих рейдов ну разве кроме последних моделей понятия неимеет о триме. Производителям не нужна конкуренция новым дорогим моделям со стороны старых, так что ждать обновлений биоса как погоды у моря. И что многие жалуются на ужасное - ужасное падение производительности ? Кеп покажи как ты умеешь гуглить :-))

> Хинт: если бы все было так как ты говоришь, никто не стал
> бы геморроиться с реализацией команды TRIM от которой и так нет
> эффекта. По-моему, это даже детсадовцу понятно? :)

Трим маркетинговый ход на который есть патент :-)) или не ?

> Проблема в том что в ZFS крайне маловероятно что блок ФС совпадет
> с блоком SSD.

Месье не делал но знает ...
> Поэтому - да, ты очень хорошо подсказываешь -
> часто будет тереться ДВА блока там где хватило бы одного. Ну
> а с блоками переменного размера ты еще и никогда не сможешь
> выровнять ФС так чтобы ее блоки совпали с блоками флеша.

И все же это реально ...
> Так
> что многие блоки ФС попадут на пересечение блоков флеша. Вот ить
> незадача то. Тут вам и двукратный wear, и более тормозная запись
> лишний раз.

Так тестов никто и не привел ...
> В случае с TRIM это не такая уж проблема,
> т.к. erase не будет и будет только программирование страниц по количеству
> записываемого. А вот без него логика контроллера свалится в черти-какой штопор.
> Грубый прикидон мне подсказывает что экстенты + trim будут работать не
> в пример лучше, т.к. в идеальном случае SSD просто запрограммит страницы
> и по объему желаемой записи и ... все :). Юзание TRIM
> порядочно приближает к этому идеалу. Без него будет максимально паршивый сценарий
> вообще каждый раз.

Сан юзает ссд диски под кеш zfs и знать незнает что использует их неоптимально ... вот что бывает когда инженеры сана не читают каменты анонимусов на опенете :-))) ...

> Ну да, ну да, и угадать размещение блока ФС чтобы не попало
> на границы блоков флеша, когда будет на ровном месте тереться 2
> блока вместо 1 просто потому что блок ФС угораздило же лежать
> в обоих. А блоки переменного размера окончательно испортят компот, сделав это
> начинание невозможным. Не говоря о том что тратить блок 512Кб на
> файлик в 1Кб размером будет достаточно обидно.

А в других фс не обидно ...

> Минимальной единицой записи в флеш является страница. Есть более крупные блоки -
> группы страниц, стирание в 0 происходит только большими группами. Ты о
> каких из блоков?
> Значит, видимо, об erase-блоках. Теоретически, если тебе удастся разложить блоки ФС с
> 512-Кб блоками так чтобы они совпали с секторами флеша - ты,
> натурально, выиграешь по скорости записи. Практически - флаг тебе в руки
> это сделать в ZFS с ее блоками переменного размера и смотри
> не удавись от жабы когда файл 1 Кб начнет жрать 512Кб
> блок, если это вдруг получится.

А ьы хотели бд на zfs и там вообще 10 файлов максимум ...

> С одной стороны, прикольно что до изена стало доползать как выравнивать фс
> на блоки флеша. С другой - я бы посмотрел как ты
> ZFS на блок флеша выровняешь :D.

gnop create -S 4096 /dev/gpt/disk0
zpool create -o altroot=/mnt -o cachefile=/var/tmp/zpool.cache zroot /dev/gpt/disk0.nop
Это ?

> Кроме размера должны еще и границы блоков совпасть. А вот это уже
> не самое простое требование. А с блоками переменного размера - ну
> ты понял, да? :)

Так чтоли zfs set recordsize=128k tank/mysql/iblogs ?

> В клиническом случае может и не успеть. Вот только в этом случае
> SSD придется менять с регулярностью чартерных рейсов. У современного MLC ресурс
> не больно огромный, порядка нескольких тысяч циклов всего. Так что (в
> идеальном случае) несколько тысяч записей объемом с накопитель и усе, он
> начнет рассыпаться. В реальном даже меньше благодаря упомянутым неоптимальностям.

Вот такое Г... просто ненужно покупать.

> В режиме когда GC не успевает разгребаться, ресурс будет "ой, опять пора
> менять SSD" :). А в менее суровых случаях имхо ФС с
> trim выиграют.

У ссд есть гарантия. Главое чтоб он сдох до того как она закончится :-))
Как же там все темно http://habrahabr.ru/post/143659/ дословно:
Если у вашего SSD контроллер SandForce 2***, то TRIM вам не рекомендуется. Как говорят очевиды всё дело в том, что контроллер SF2*** обрабатывает удалённую пользователем информацию своим особым образом и вообще хранит данные на диске в виде одного большого архива ...
Вобщем идем по ссылке в статье ищем свой диск и определяем нужен трим или нет.