SSD, fstrim и mount -o discard

Система не помнит, какие блоки (из не занятых данными) ранее были подвергнуты TRIM'у.

Понятно, спасибо.

К слову, видимо, ext234 всё-таки кэширует это в памяти, поэтому второй раз подряд fstrim работать не будет (в смысле, скажет «0 bytes were trimmed»). Но после перезагрузки стейт предсказуемо теряется.

Но после перезагрузки стейт предсказуемо теряется.

Так если работа с устройством ведётся, то, спустя непродолжительное время, там будут новые неочищенные блоки. Может, это не ФС кэширует, а устройство исполняет команты не мгновенно, и, получив задание от fstrim, ещё долго работает ? Никто в код не смотрел ? Действительно, интересно...

Кстати, ещё интересно получить стастистику по неочищенным блокам, если таковое, вообще, возможно...

спустя непродолжительное время, там будут новые неочищенные блоки

Так и есть. Но вновь появляющиеся свободные блоки обрабатываются в реалтайме.

Может, это не ФС кэширует, а устройство исполняет команты не мгновенно, и, получив задание от fstrim, ещё долго работает ?

И fstrim, и сама команда TRIM выполняются синхронно. Даже если fstrim выполнялся бы асинхронно, на время фактического discard'а система вставала бы колом.

Никто в код не смотрел ?

Там (в ext234) совершенно точно два битмапа. Я смотрел в код, когда писал поддержку discard для reiser4.

Так и есть. Но вновь появляющиеся свободные блоки обрабатываются в реалтайме.

То есть, fstrim вообще больше до перезагрузки не запустится ? Ну или отмонтирования раздела и монтирования обратно.

И fstrim, и сама команда TRIM выполняются синхронно. Даже если fstrim выполнялся
бы асинхронно, на время фактического discard'а система вставала бы колом.

Почему ? Такая же операция, как запись. Я что-то думал, что смысл trim в том, чтобы успевать готовить накопитель к записи при маленьком потоке данных, чтобы он был готов быстро отработать при большом без затрат времени на стирание. А если стирать синхронно, то это же тоже замедление, только не записи, а удаления. Так как-то не интересно.

Вообще, возник какой-то непонятный косяк. SSD-шка долго работала (несколько месяцев) с примерно постоянным потоком на запись. ext4, в опциях discard изначально. Некоторое время назад сильно взлетел i/o wait. Идёт от приложения, которое пишет на SSD. Первая посетившая мысль - что trim работает медленнее потока, и, наконец-то, закончились очищенные блоки. Хотя, пока, не очень подтверждается: пятиминутная остановка приложения сильно ситуацию не спасает, i/o wait взлетает почти сразу после запуска.

Если fstrim работает синхронно с реальной очисткой, то он что-то больно быстро это делает: 40Гб пробегает минуты за три. Сильно маленькая задержка на стирание одного блока, столько и при записи не жаль: 17 микросекунд на один 4K блок получилось. Ну и ситуация после fstrim не исправилась.

То есть, fstrim вообще больше до перезагрузки не запустится ?

Запустится, но ничего (или почти ничего) не будет делать. Есть случаи, в которых realtime discard не срабатывает; это зависит от используемых в ФС алгоритмов.

Почему ? Такая же операция, как запись.

Однако, до какой-то там ревизии SATA эта команда должна исполняться при пустой очереди («Trim has been defined as a non-queued command by the T13 subcommittee», https://en.wikipedia.org/wiki/Trim_(computing)#Shortcomings).

Я что-то думал, что смысл trim в том

Смысл TRIM в том, чтобы балансировщик нагрузки (который время от времени переназначает логические сектора на разные физические) знал, какие сектора пустые.

https://en.wikipedia.org/wiki/Write_amplification

Если fstrim работает синхронно с реальной очисткой, то он что-то больно быстро это делает: 40Гб пробегает минуты за три.

Что-то это очень дофига. У меня (OCZ Vertex 4, 120 GB) полная очистка всего диска занимает секунд десять.

Что-то это очень дофига. У меня (OCZ Vertex 4, 120 GB) полная очистка всего диска занимает секунд десять.

А ты уверен, что у тебя что-то там вообще очищается?

Уверен, мамой клянусьhdparm --read-sector соврать не даст.

Смысл TRIM в том, чтобы балансировщик нагрузки (который время от
времени переназначает логические сектора на разные физические) знал,
какие сектора пустые.

Всё же нет. Write amplification - второе следствие этой же проблемы. А первопричина - необходимость записи в пустую ячейу, которая должна быть предварительно очищена. Плюс термин «сборщик мусора» («garbage collection») обычно подразумевает асинхронную работу. Я как-то так полагал, что для SSD аналогично.

И, видимо, не очень ошибся, некоторые SSD так умеют:
http://en.wikipedia.org/wiki/Write_amplification#BG-GC

Some SSD controllers implement background garbage collection (BGC), sometimes called idle garbage collection or idle-time garbage collection (ITGC), where the controller uses idle time to consolidate blocks of flash memory before the host needs to write new data. This enables the performance of the device to remain high.

Что-то это очень дофига. У меня (OCZ Vertex 4, 120 GB) полная
очистка всего диска занимает секунд десять.

Похоже, SSD-шка моя таки не выдержала полугодового издевательства с записью. Вообще, была надежда, что продержится больше года хотябы... Только непонятно, почему скорость упала, а не сама возможность записи пропала. Или оно так и происходит перед переходом в r/o ? В результате, как раз, исчерпания скрытого запаса ? Но в SMART ничего подозрительного нет вроде.

Всё же нет. Write amplification - второе следствие этой же проблемы. А первопричина - необходимость записи в пустую ячейу, которая должна быть предварительно очищена.

Согласен.

BGC

Я как-то не совсем представляю, что понимается под «консолидацией блоков»...

Похоже, SSD-шка моя таки не выдержала полугодового издевательства с записью.

Странно, уже упомянутый Vertex 4 жил у меня около двух лет в достаточно агрессивном режиме (10 GiB в день — легко). И то, «жизнь прервалась» в результате кражи ноута, а не отказа диска. По его внутреннему смартовскому счётчику ресурса оставалось около 90%.