The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Индекс форумов
Составление сообщения

Исходное сообщение
"Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."
Отправлено Аноним, 26-Авг-12 22:15 
> Операция TRIM нужна там,

Операция TRIM нужна чтобы контроллер SSD мог разгребать мусор осмысленно и заранее. А не судорожно надрываться в ситуации когда уже приперло - записать надо, а чистых регионов нет. Потому что фиг бы его знает: используется вон тот блок файловой системой или нет. SSD этого не знает. Поэтому вынужден хранить все вплоть до момента пока кто-то не возжелает явно перезаписать этот блок. По поводу чего GC в SSD сваливается в очень неоптимальный режим - что-то типа твоего пула забитого до отказа получается, но в рамках одного накопителя. В случае TRIM - файловая система явно хинтит что "а вот этот кусок мы более не используем". По поводу чего SSD может заранее его разгрести. После чего и запись быстрее, и wear leveling куда меньше надрывается когда приспичило что-то записать.

> записи на флэш выполняется блоком страниц 512 кбайт.

Вообще-то она выполняется страницами, они порядка 1-4 кб, но это получается не всегда - в зависимости от того что было записано ранее. Если не получается оформить как запись чистых страниц - тогда стирается весь блок. Операция стирания достаточно длительная. Пока она происходит, писать данные невозможно. И данные курят бамбук, ожидая пока будет подготовлен регион. В случае с TRIM SSD это может сделать заранее. Без него - опаньки.

Т.е. если повезло, запись проходит как page write(s) -> готово.

> Размер блока на ZFS может быть настроен равным размеру блока страниц SSD

...но это не отменит того факта что SSD не будет знать используется ли некий блок. И не сможет очистить незанятые заранее.Поэтому при попытке записи сие будет выглядеть как: Read -> GC -> erase -> page write(s). Как-то больно дофига супротив первого варианта, не находишь? Не говоря о том что ssd сильно ограничен в возможности оптимизировать сбор мусора и оптимизировать циклы стирания и вообще wear leveling. Да, выделение блоков по размеру erase block может несколько скостить неоптимальность. Но тут есть одно большое но. Чтобы это случилось, блок должен попасть точно по границе сектора флеша. А поскольку геометрию флеша не видно, эта задача превращается в mindfuck. То-есть ты должен железно знать как ФС блоки раскидывает и подобрать смещение чтобы они попадали по границам секторов флеша. Кстати а блоки переменного размера отключить можно? А то они в этом случае все попортят - стоит воткнуть блок менее 512Кб как границы остальных блоков на ним перестанут совпадать с секторами флеша. И чтобы записать 1 блок придется тереть 2 сектора (просто потому что на пересечение оных попали). В 2 раза больше wear'а на ровном месте.

У экстентных схем с этим несколько проще: даже если экстент и не попадает в границы блоков, возможность одним махом сделать экстент на 100500 мегабайтов обеспечит относительно небольшую (в процентах) неоптимальность, т.к. все блоки кроме крайних заведомо пишутся по 1 разу.

> (512 кбайт вместо 128 кбайт), нужда в операции TRIM исчезает —

Мечтать не вредно.

 

Ваше сообщение
Имя*:
EMail:
Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email).
Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
  Введите код, изображенный на картинке: КОД
 
При общении не допускается: неуважительное отношение к собеседнику, хамство, унизительное обращение, ненормативная лексика, переход на личности, агрессивное поведение, обесценивание собеседника, провоцирование флейма голословными и заведомо ложными заявлениями. Не отвечайте на сообщения, явно нарушающие правила - удаляются не только сами нарушения, но и все ответы на них. Лог модерирования.



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру