Comments 81
У самого на днях система на RPi не поднялась после перезагрузки. Всего одна новая программа за две недели убила microSD, которая до этого стабильно работала около 2-х лет.

По теме на хабре есть большая статья с не менее большими комментариями — «Малиновый Прог против Интернета Кирпичей, или Raspberry Pi с графикой на read-only microSD»
Иногда read-only-система неудобна или нецелесообразна на одноплатниках, в этом случае описанные действия позволят выявить и отключить лишнее. Также, например, Libre Computer предоставляет образы ОС в btrfs в качестве основной файловой системы, и я до анализа её поведения на своем компьютере и написания этой статьи не знал, что усиление записи настолько сильное.
Статья несомненно полезна, но Вы меня конечно простите, но вы какие-то странные ребята, я про автора статьи, который цитирует рекомендации по переносу профиля на hdd чтобы меньше писать на ssd и пожертвовать скоростью ради сохранности ssd.

Для чего я покупаю SSD? В первую очередь для того чтобы быстро на него писать данные и еще быстрее читать эти данные, и мне пофиг будет ли на ssd профиль гуглохрома или еще какой-то программы которая будет насиловать диск, главное что эти программы работают быстро — что мне и нужно.
Берите дешевые ssd, размещайте на них только ОС, а критически важные данные храните на hdd ну и конечно делайте бэкапы.
Я раз в месяц снимаю с ssd где стоит ос образ и если он умрет я без сожаления его выкину, пойду и куплю новый ssd за 3 т.р., разверну образ ОС за 10 минут и продолжу работать. А заниматься ерундой по вычислению сколько какая программа пишет — увольте.
За 6 лет это у меня уже третий SSD, т.е. SSD в моем ноутбуке в среднем нормально работает 2 года, заметьте, с учетом того, что большая часть часто изменяющихся данных находится на HDD. Это очень мало, аномально мало, поэтому я и начал разбираться. Если бы SSD не выходили из строя, а работали так, как обычно пишут комментирующие, я бы не заморачивался, и не узнал об огромном коэффициенте увеличения записи в btrfs. А ведь её люди и на MicroSD используют.

А заниматься ерундой по вычислению сколько какая программа пишет — увольте.
Статья также полезна для выявления значительных проблем ПО. Например, в 2016 году Spotify очень часто выполнял команду VACUUM на sqlite-базе, что приводило к записи до 700 ГБ в сутки на диск. Один такой Spotify, и гарантия на ваш диск истечет через полгода после покупки. Программа неправильно работала в течение 5 месяцев.
arstechnica.com/information-technology/2016/11/for-five-months-spotify-has-badly-abused-users-storage-drives
За 6 лет это у меня уже третий SSD, т.е. SSD в моем ноутбуке в среднем нормально работает 2 года, заметьте, с учетом того, что большая часть часто изменяющихся данных находится на HDD.

У меня SSD живут намного дольше. Моему ThinkPad с единственным SSD на 256 Гб уже 5 лет, и я его ресурс никак не экономил. Использовал и swap и торренты качал все это время (не очень активно, но регулярно). И btrfs с dm-crypt использовал. Диск живой и никакого снижения производительности.


За статью спасибо. Увы, думаю, такие эпизоды как со Spotify будут ждать нас все чаще. :(

Наверное и SSD у вас на SLC или MLC, сейчас подавляющее большинство дисков это TLC или QLC, ресурс у них в стони и тысячи раз меньше

А как узнать тип SSD? Искать по номеру модели?
Thinkpad купил в 2014-м году. Думаю тогда уже не было в бытовом сегменте SLC или MLC.

MLC даже сейчас вполне есть.
вот зимой прошлой купил samsung 970 pro, например.
MLC в продаже ещё есть, желающие могут успеть. Как SATA, так и NVME. Samsung серии Pro возможно будет выпускаться и далее, но цена на него будет всегда очень высокой.
да не сказать что прям дорогой.
я за 12500 брал. щас даже дешевле. летом где-то за 10000 видел.

Так в чём проблема купить сейчас SSD на MLC? Ну кроме того, что цена в полтора раза выше.

Дак не используйте btrfs. В чем ее плюсы для домашнего использования? Скорость? Надежность? А, что классика ext4 уже для дома не надежна или медлительна? Нет. Дак в чем профит? Но все равно мыши плакали, кололись, но продолжали использовать btrfs.

А может у Вас старая версия ядра и btrfs? Посмотрите тут и сравните с тем что у Вас. А еще прочитайте про профиль хранения данных в btrfs (при создании раздела SSD detected было yes ?) и вот это в официальном FAQ

Ну и самое главное — зная архитектуру btrfs (хорошая статья):
К сожалению, btrfs «благодаря» своей архитектуре крайне подвержена такому явлению, как фрагментация. Дело в том, что данные записываются всегда в новое расположение на диске. Даже если прочитать файл, ничего не сделать с данными и записать их обратно в тот же файл, то данные попадут на диске в новую область. То же самое произойдет, если обновить данные в файле только частично — изменения запишутся в новую область на диске.

Можно сделать вывод, что «насиловать» SSD она будет всегда, остается лишь поднастроить ее, чтобы это было в пределах нормы.

Ну и каждые 2 года новый SSD — конечно маловато, но один то SSD у вас по вине контроллера умер, то есть это был скорее всего брак и если исходить из отсутствия брака, то получается каждые 3 года новый SSD — по-моему вполне нормально, если Вы не будите покупать супер-дорогие, а остановитесь на дешевых.

Профит btrfs для домашнего пользователя в снэпшотах. Правда, я не очень часто их использую, но приятно знать, что такая возможность существует. Например, их можно использовать для резервного копирования, для инкрементального резервного копирования.

Накладные расходы при использовании снапгоиов там СИЛЬНО выше чему у btrfs

Поддержу.
У меня настроено автоматическое создание снепшотов через cron. И удаление их через 14 дней.
Очень удобно. За считанные секунды откатиться на любую дату, а потом обратно.
SSD у меня родной в MacBook Pro 2013 года.
Соответственно ему 6 лет. И SWAP, и профиль, и виртуальные машины — все на нем.
Никаких проблем не наблюдается…
С HDD использовать такую схему не настолько комфортно. Там приходится делать принудительную дефрагментацию, минимум раз в 3 месяца. Иначе начинаются «залипания» по несколько секунд. Во время дефрагментации производительность диска падает практически до нуля.
Но если настроить авто дефрагментацию в период минимальной нагрузки — вполне можно жить.
Дак не используйте btrfs. В чем ее плюсы для домашнего использования? Скорость? Надежность? А, что классика ext4 уже для дома не надежна или медлительна? Нет. Дак в чем профит? Но все равно мыши плакали, кололись, но продолжали использовать btrfs.
Раньше я везде использовал только ext4, но в Fedora btrfs предлагается по умолчанию, и я решил использовать её. В btrfs очень удобная функциональность снапшотов. Понятно, что можно использовать ext4 на lvm, но btrfs просто удобней, хотя бы в силу того, что я несколько раз создавал ФС с не очень большим количеством inode, а потом не мог распаковать что-то большое на ФС.

Версия ядра у меня одна из самых новых, это же Fedora.
К сожалению, btrfs «благодаря» своей архитектуре крайне подвержена такому явлению, как фрагментация. Дело в том, что данные записываются всегда в новое расположение на диске. Даже если прочитать файл, ничего не сделать с данными и записать их обратно в тот же файл, то данные попадут на диске в новую область. То же самое произойдет, если обновить данные в файле только частично — изменения запишутся в новую область на диске.

Можно сделать вывод, что «насиловать» SSD она будет всегда, остается лишь поднастроить ее, чтобы это было в пределах нормы.

Что вы имеете ввиду, вменяя в данном случае фрагментацию как недостаток? Ведь для SSD эта проблема неактуальна. Да, фрагментация может появиться, но, так как в SSD нет движущихся деталей, ухудшить скорость работы она не может.
Для SSD эта проблема также актуальна, но не так сильно выражена, как для HDD. SSD может обеспечивать, скажем, 3200 МБ/с линейного чтения и 40 МБ/с случайного, а HDD — 250 МБ/с линейного и 1 МБ/с случайного.
Извините, но я усомнюсь, все-таки основной урон от фрагментации вызван лишними движениями магнитных головок и ограничений механики, которой в SSD нет. И я никогда не слышал чтобы фрагментация как-то влияла на SSD, а скорее даже наоборот. Вы не могли бы привести пруф, пожалуйста?
Посмотрите любой тест SSD на случайное чтение. Обычно тестируют случайное чтение блоками по 4 КБ, что мало для реальных ФС, но кое-какое представление о разнице в скорости между линейным и случайным чтением, а следовательно, о воздействии фрагментации дать может.
Еще бы хотел добавить, что запись всегда в новое место естественным образом реализует выравнивание износа ячеек. Что для твердотельного накопителя плюс.

Я лично не встречался, но много раз слышал как флешки быстро умирали при использовании журналируемых ФС (ext4, ntfs etc.) Считается, что это происходит из-за того что журнал, находящийся в одном месте, постоянно обновляется и это вызывает очень быстрый износ ячеек.
Еще бы хотел добавить, что запись всегда в новое место естественным образом реализует выравнивание износа ячеек. Что для твердотельного накопителя плюс.

Глупость. В SSD используется таблица трансляции, контроллер каждый раз пишет данные в новое место.


Я лично не встречался, но много раз слышал как флешки быстро умирали при использовании журналируемых ФС

А вот во флешках контроллер тупой.

Спросите об этом производителя конкретного SSD.
Пишется она тоже на флеш, но вполне возможно, что из-за относительно небольших размеров таблицы это могут оказаться SLC-ячейки с огромным ресурсом

Ведь для SSD эта проблема неактуальна

Ещё как актуальна, и связано это, в первую очередь, с износом ячеек, а не со скоростью.


Дело в том, что нельзя просто взять и записать новые данные поверх старых. Нужно считать данные, полностью стереть ячейку (а это около 512кб), а потом их записать обратно с изменениями.


В случае последовательной записи маленькими фрагментами контроллер имеет возможность консолидировать данные и обойтись одной перезаписью, но в случае рандомной записи придётся перезаписывать ячейку на каждый чих. Потому это и приводит к высокому Write Amplification.

контроллеру SSD совершенно пофиг, что вы считате рандомной записью, а что последовательной
он забирает из буфера данные, записывает их туда, куда считает нужным и сохраняет операцию у себя в табличке
когда кончаются тримнутые ячейки — да, производительность деградирует, ну так и это тоже забота контроллера, следить, чтобы запас был, а если он не успевает, значит вы выбрали неподходящую для вашей задачи модель
контроллеру SSD совершенно пофиг, что вы считате рандомной записью, а что последовательной

Если бы ему было пофиг, то в тестах на скорость записи/чтения не было бы разницы между случайной и последовательной записью.


он забирает из буфера данные, записывает их туда, куда считает нужным и сохраняет операцию у себя в табличке

Контроллер оперирует на уровне блоков флеш-памяти — вот их он и может тасовать как ему вздумается, при этом деградации вскорости не будет.


когда кончаются тримнутые ячейки — да, производительность деградирует, ну так и это тоже забота контроллера, следить, чтобы запас был, а если он не успевает, значит вы выбрали неподходящую для вашей задачи модель

Это не забота контроллера, а забота драйвера файловой системы. Контроллер никак не может узнать, свободна ли ячейка или нет, пока вы ему не скажете об этом явно.

Если бы ему было пофиг, то в тестах на скорость записи/чтения не было бы разницы между случайной и последовательной записью.

ну да, не совсем пофиг, внутренний конвейер же тоже страдает, ок

Контроллер оперирует на уровне блоков флеш-памяти — вот их он и может тасовать как ему вздумается, при этом деградации вскорости не будет.

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

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

эмм, так-то контроллер их записывает, читает и удаляет, он обязан знать, где свободные ячейки, а где занятые
ОС вообще не в курсе про этот низкий уровень, для неё любой накопитель выглядит, как набор LBA
не совсем так, очищен может быть только блок целиком, оперирует контроллер всё-таки традиционными страницами

Да, это так. Дописать страницу в свободную часть блока — легко, прочитать страницу — легко. Но перезаписать страницу — тяжело, нужна полная очистка блока.


Плюс последовательно идущие логические страницы в итоге все равно должны быть записаны в один блок, иначе будет дико страдать производительность в том числе и на чтение из-за большого количества уровней индирекции.


эмм, так-то контроллер их записывает, читает и удаляет, он обязан знать, где свободные ячейки, а где занятые
ОС вообще не в курсе про этот низкий уровень, для неё любой накопитель выглядит, как набор LBA

Так ОС явно и говорит, что надо почистить. Конечно, есть модели SSD, где физически ячеек больше, чем доступно ОС, этот объём и используется контроллеров для собственных нужд.

Не могли бы вы указать на конкретные модели ssd, которые вы использовали?
Первый — OCZ Nocti 32 GB msata
Второй — Plextor M5M 128 GB msata
Сейчас — Samsung EVO 860 256 GB msata.
вот это цифры… прочитав статью, судорожно полез на свой сервак, в который впихнул 860-ю прошку от самсунга. (они обещают 600 tbw для моего размера — тоже как-то «подозрительно вечный» диск, ну, под мои нужды, конечно)

За 6 месяцев — 6 с небольшим терабайт и это сборочный сервак (ci) в отделе из 10 человек, а в статье ноут в монопольном доступе для одного человека — почти 20 тб за 7 месяцев… чудесато…
а в статье ноут в монопольном доступе для одного человека — почти 20 тб за 7 месяцев… чудесато…

Write amplification — ужасная штука

Когда-то, в 2013-2014 был большой и длительный «петабайтный тест». По результатам того теста я купил себе Samsung SSD 850 PRO 256GB.
Он уже работает более 5-и лет и на него записано более 30-и ТиБ. По показометру он исчерпал только 10% ресурса. Я на пенсию раньше выйду чем он помрёт. :-) Этот SSD — единственный в компе, на нем делаю всё, и домашнее, и рабочее. Использую ext4. Каждую ночь делается LVM snapshot и с него обычный инерементарный бэкап на внешнее файлохранилище (tar -g). Раз в неделю делается fstrim, опцию монтирования ФС «discard» не использую.


SMART
# smartctl -i /dev/sda
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.19.7-1] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Samsung based SSDs
Device Model:     Samsung SSD 850 PRO 256GB
Serial Number:    S251NXAGB25293J
LU WWN Device Id: 5 002538 8400fe803
Firmware Version: EXM02B6Q
User Capacity:    256 060 514 304 bytes [256 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-2, ATA8-ACS T13/1699-D revision 4c
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Tue Nov 19 19:15:32 2019 +03
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

# smartctl -A /dev/sda
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.19.7-1] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0032   090   090   000    Old_age   Always       -       45510
 12 Power_Cycle_Count       0x0032   099   099   000    Old_age   Always       -       93
177 Wear_Leveling_Count     0x0013   090   090   000    Pre-fail  Always       -       578
179 Used_Rsvd_Blk_Cnt_Tot   0x0013   100   100   010    Pre-fail  Always       -       0
181 Program_Fail_Cnt_Total  0x0032   100   100   010    Old_age   Always       -       0
182 Erase_Fail_Count_Total  0x0032   100   100   010    Old_age   Always       -       0
183 Runtime_Bad_Block       0x0013   100   100   010    Pre-fail  Always       -       0
187 Uncorrectable_Error_Cnt 0x0032   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0032   062   039   000    Old_age   Always       -       38
195 ECC_Error_Rate          0x001a   200   200   000    Old_age   Always       -       0
199 CRC_Error_Count         0x003e   100   100   000    Old_age   Always       -       0
235 POR_Recovery_Count      0x0012   099   099   000    Old_age   Always       -       47
241 Total_LBAs_Written      0x0032   099   099   000    Old_age   Always       -       74207594731

Статья интересная и полезная, спасибо. Никогда не знаешь заранее откуда ждать неприятности, как со спотифаем. Или с очередной ФС. :-)

В 2011 году я купил себе OCZ RevoDrive X2 240 GB за $600, использовал его, не жалея ресурса (24/7, виртуалочки, торренты, своп). Записано около 80 ТБ "грязными" (с учётом компрессии компресии контроллером — около 20 ТБ), ресурс выработан всего на 2%.


Скорее PCI-E слоты станут устаревшими, чем выработает ресурс это чудо.

Есть 3-х летний тест ssd на износ от 3dnews — Надёжность SSD: результаты ресурсных испытаний — 1.09.2016 — 4.09.2019; выводы:


Во-первых, заявляемая производителями выносливость SSD – параметр, не имеющий никакого отношения к реальной надёжности.… Во-вторых, современные накопители, по крайней мере если говорить о свежих и качественных моделях ведущих производителей, больше не подвержены внезапной и необъяснимой гибели.… Вне всяких сомнений наилучшие по надёжности накопители на данный момент получаются у компании Samsung, которая применяет 3D V-NAND собственного производства. Весьма неплохую жизнестойкость также показывают и те SSD, в которых используется планарная MLC NAND компании Toshiba.

В их "методике" бывают проверки смарт атрибутов и вычисление фактического коэффициента усиления записи на их тесте. Достаточно ли поделить обнаруженный 3dnews ресурс (с учетом очень слабой статистики в 1 экз.) в 2, 4 или 8 раз, чтобы согласовать их результаты с предполагаемым вами уровнем усиления записи на "реальных" тестах?
Как ваша методика согласуется с научными публикациями (например https://storageconference.us/2016/Papers/ReducingWriteAmplification.pdf https://www.snia.org/sites/default/files/SDC15_presentations/performance/ZhenyunZhenyun_Designing_SSD.pdf#page=32)? Использовали ли вы симуляторы трансляторов? (например FTLSim)

Я может ошибаюсь, но если SSD исчерпал свой ресурс до окончания гарантии — то разве его по гарантии не заменить?

Нет, конечно. Такая халява была только для самых первых SSD, чьи производители были уверены, что ресурс диска не исчерпается за разумное время.

Его можно заменить по гарантии только к том случае, если он сломается и его ресурс его записи будет не выше, чем указано в гарантии.
> За 6 лет это у меня уже третий SSD, т.е. SSD в моем ноутбуке в среднем нормально работает 2 года

Это странно. Использую btrfs везде, в т.ч. на microsd, emmc, флешках с 2011/2012 года (точно не помню) за это время заподозрить btrfs я могу разве что в отношении переставшего загружаться DEXP Ursus 7W (зависание на лого BIOS, перед запуском GRUB2) и то не факт что там запилена emmc, а не просто китайский планшет накрылся. Все остальные накопители (среди которых десятки SSD) в том числе мой самый первый SSD (Crucial M500, если не изменяет память) до сих пор живы и здоровы.

На мой взгляд вам стоит искать причину неисправности этих SSD не в файловой системе.
Я не виню btrfs в выводе из строя SSD, но то, что у неё усиление записи на порядок выше других файловых систем — факт.
> Вывод: не стоит использовать btrfs, если программы часто записывают небольшое количество данных (несколько килобайт)

Одна из ключевых фишек Btrfs — поддержка сжатия на лету (zstd, zlib, lz4). Естественно, далеко не все данные хорошо сжимаются, но некоторые ужимаются очень хорошо, как известно. Так что каковы, в таком случае, будут значения коэффициента усиления записи — вопрос открытый. Понятно, что на размерах в несколько килобайт (то есть одна-две 4k-страницы) вряд ли что-то сильно поменяется, но есть и другие шаблоны записи на диск, естественно. Будет ли в итоге выигрыш, или же нет — вопрос мало того, что открытый, так еще и несколько индивидуальный.

Кроме того, нужно помнить, что Btrfs — использует парадигму Copy-on-Write, что подразумевает лучшее распределение записи по всему объему, а не перезапись in place.
UFO landed and left these words here
> Этим, вообще-то, контроллер SSD занимается

1. Использование «вообще-то» какБыНамекает™ звучит так, что информация выше неверна. А это не так.

2. Чем занимается отдельно-взятый контроллер (ресурсы которого, по сравнению с системными, довольно скромные), как правило, известно мало. На Github'е их как-то не много. :) Кроме того, там бывают баги, и даже обновления прошивок, которые, естественно устанавливаются далеко не всеми, и не всегда. Другими словами — шансы получить обновление, на уровне OS, существенно выше, чем на уровне контроллера.

3. Как известно, зачастую трансляция одной парадигмы в другую — менее эффективна, чем изначальное следование целевой. Именно по этой причине для SSD (и прочих накопителей схожих принципов) разрабатываются специализированные файловые системы (например JFFS2), где wear-levelling, опять же, является изначальным свойством самой FS.
Однако за 6 лет я пользуюсь уже третьим SSD: у первого вышел из строя контроллер, а второй начал перемещать данные между ячейками
Контроллер выходит из строя не из-за износа ячеек.
Третий SSD — это значит, что за шесть лет у вас их накрылось два штуки. С нынешним мусорным качеством — вполне в рамках, HDD.бывает, и того меньше живут.
Огромная амплификация при записи небольшого количества данных

А ещё есть у SSD одно свойство, что-то вроде необходимости записать все 512 байт «сектора» при записи любой информации. Так, нашел точнее инфу:
Спойлер
Одно из функциональных ограничений SSD заключается в том, что чтение и запись с/на пустой диск происходит очень быстро, а вот перезапись информации в разы медленней. Это из-за того, что когда SSD читает информацию на уровне страницы (в значении отдельных строк в памяти типа NAND) и могут записывать тоже на уровне страницы, предполагая, что окружающие ячейки пусты, они могут удалять данные только на уровне блоков. Это потому, что акт стирания NAND памяти требует большого напряжения. Хотя теоретически вы можете стереть NAND память на уровне страниц, объем требуемого напряжения устанавливается запросом отдельных ячеек вокруг ячейки, которая переписывается. Стирание данных на уровне блока помогает смягчить эту проблему.

То есть «записать 1 байт» так просто не получится. И ещё я не в курсе — как создаются сектора при технологии «3 бита на ячейку» — скажем 512 на 3 не делится.
ECC тоже хранить надо, хотя не знаю хранится ли, вроде у твердотельников писали 4кб сектора, хотя у макбуке пишет что там 512

Видимый на шине (SATA,SCSI,SAS) размер сектора не совпадает с физическими секторами и в HDD и у CD/DVD и у SSD. Для HDD см иллюстрацию в https://www.thomas-krenn.com/en/wiki/Advanced_Sector_Format_of_Block_Devices — например 50 байтов ecc на 512 байтов логического сектора, плюс Gap, sync, address. Или https://lenovopress.com/redp5119.pdf — смысл в переходе на 4 КБ сектора был в экономии места.
У SSD биты для хранения ECC есть внутри физических страниц в чипах флеш-памяти и обрабатываются контроллерами — https://www.atpinc.com/blog/ldpc-ssd-low-density-parity-check-ecc-algorithm (64 байта ecc на 2КБ), https://www.usenix.org/system/files/fast19-kim-bryan.pdf, иногда более сильные системы исправления — https://www.micron.com/~/media/documents/products/technical-marketing-brief/brief_ssd_rain.pdf

3 бита — это, грубо говоря — от 000 до 111 в двоичной системе. То есть делить 512 надо на 8

Что-то Вы не то говорите. 3 бита — это 3 бита. Требуется для задания разделять уровни заряда, которые можно условно сопоставить значениям от 0 до 7.
При чтении/записи SSD оперируют страницами, а не секторами, размер страницы может быть от 2 до 16 кб (зависит от конкретной модели), соответственно запись 1 байта никак не может занять меньше 2K в лучшем случае.

Ситуация ухудшается если вам нужно не записать а изменить 1 байт — сначала он прочитает страницу с этим байтом, поменяет в прочитанном блоке этот самый байт, а потом пойдёт искать пустую страницу в которую его можно записать, отметив старую как «грязную» (т.е. использованную но не доступную для записи).

Всё усложняется тем что хоть писать и можно на уровне страницы, запись не может быть сделана «поверх» — сначала нужно стереть аж целый блок (состоящий из многих страниц, от 256K до 4M), и только потом писать.

Если пустых страниц нет (диск был записан полностью как минимум один раз, при этом TRIM не использовался — частый случай когда SSD используются в RAID), то всё просто кошмарно — контроллер сначала читает весь блок, где находится тот злосчастный байт, читает его весь (да, до 4M), стирает его и перезаписывает полностью. На самом деле чуть сложнее — он может попытаться начать джонглировать блоками в рамках оптимизации износа и сборки мусора, ища то что реже всего стиралось и перетасовывая найденное в процессе, вовлекая в процесс резервную зону (недоступную для обычного использования).

Разумеется, всё это дорого обходится — производительность падает, и чем дальше тем больше. TRIM помогает сильно улучшить ситуацию, но, как я уже сказал раньше, не все RAID контроллеры его поддерживают (увы), хотя для «домашних» применений (нет RAID и система поддерживает TRIM) всё достаточно неплохо (если диск под завязку не забит).
Статья отличная, но многие читатели спросят:
Почему мой SSD по формуле
Чтобы получить байты, нужно умножить значение параметра на 512.
показывает такое маленькое значение.
241 Total_LBAs_Written 0x0032 100 100 000 Old_age Always - 38360

Что получается очень мало для активного в работе диска
38360 × 512 ÷ 1000 ÷ 1000 ÷ 1000 ÷ 1000 = 0.00001964032 ТБ

На самом деле если обновить базу smartctl
параметр 241 превращается… в Host_Writes_32MiB
241 Host_Writes_32MiB 0x0032 100 100 000 Old_age Always - 38360

И умножать надо на 32MiB, а не 512 байт.
На старых системах базу можно было обновить командой
/usr/sbin/update-smart-drivedb

Но на новых системах после обсуждения
bugs.debian.org/cgi-bin/bugreport.cgi?bug=804299
Такую прекрасную возможность убрали.

Поэтому если в 241 слишком маленькое значение, умножайте его на 32MiB вместо 512 байт.
Если используется Total_LBAs_Written, и SSD оперирует логическими блоками в 4 КиБ, то умножать нужно на 4096, а не на 512.
В общем, надёжней поискать информацию об интерпретации данных SMART на конкретной модели диска в документации или интернете.

Есть ещё такой запрос: smartctl -l devstat /dev/sda


smartctl 7.0 2019-03-31 r4903 [x86_64-linux-5.2.18-100.fc29.x86_64] (local build)
Copyright (C) 2002-18, Bruce Allen, Christian Franke, www.smartmontools.org

Device Statistics (GP Log 0x04)
Page  Offset Size        Value Flags Description
0x01  =====  =               =  ===  == General Statistics (rev 1) ==
0x01  0x008  4              55  ---  Lifetime Power-On Resets
0x01  0x010  4           19417  ---  Power-on Hours
0x01  0x018  6     59930947692  ---  Logical Sectors Written
0x01  0x028  6     26589423280  ---  Logical Sectors Read
0x04  =====  =               =  ===  == General Errors Statistics (rev 1) ==
0x04  0x008  4               0  ---  Number of Reported Uncorrectable Errors
0x05  =====  =               =  ===  == Temperature Statistics (rev 1) ==
0x05  0x008  1              33  ---  Current Temperature
0x05  0x020  1              33  ---  Highest Temperature
0x05  0x028  1              33  ---  Lowest Temperature
0x06  =====  =               =  ===  == Transport Statistics (rev 1) ==
0x06  0x018  4               3  ---  Number of Interface CRC Errors
0x07  =====  =               =  ===  == Solid State Device Statistics (rev 1) ==
0x07  0x008  1              24  ---  Percentage Used Endurance Indicator
                                |||_ C monitored condition met
                                ||__ D supports DSN
                                |___ N normalized value

Вообще можно много всякого про свой девайс найти в smartctl --xall ... и потом посмотреть в мане, как получить самое интересное без лишней портянки.

Намучался отучая просыпаться диск на сервере, дольше всего пришлось перепиливать пути для самбы.
Насколько я знаю, очень сильно зависит от диска. Я бы не стал покупать самые дешевые диски просто потому, что экономия будет небольшая, а, скорее всего, сделано сильное упрощение.
На хороших дисках запись не должна напрямую вести к записи в ячейку, данные должны накапливаться в оперативной памяти и записываться по мере заполнения. Конечно, усиление записи приведет к увеличению общего количества записанных данных, но от него срок службы не зависит линейно.
Вторая вещь на что смотреть — размер overprovisioning области. Эта область (как и TRIM) может помочь диску писать намного меньше в ячейки. Некоторые диски позволяют выделять эту область в процентном выражении при помощи утилит. Еще есть вариант сделать secure erase и потом разметить разделы меньше, чем размер диска. Т.о. дать диску возможность использовать эту область для перераспределения данных. Мне кажется, такое сильно поможет особенно в случаях, когда диск под завязку уже записан.
Для MicroSD это вряд ли поможет, не знаю что там.
По поводу надежности. По сути, при правильных расчетных параметрах SSD по моему предположению должны были бы быть такие же надежные как и оперативка. В реальности, по моему опыту, в сотнях новых серверов с SSD (хорошего бренда) обычно 5-10 дисков могут не работать прямо с самого начала или получить сбой почти сразу. Далее диски вылетают реже, чем HDD, но намного более часто, чем RAM и достаточно случайным образом.
Недавно надоел жутко высокий Load Average и очень низкая скорость работы MySQL на BTRFS с CoW. btrfs balance работал сутками, доводил сервер до почти неотзывчивого состояния и никак не мог завершиться. И это при том, что с самого начала использовал btrfsmaintenance для регулярных автоматических балансировок.
Нашел статью человека, который сравнил производительность MySQL на BTRFS, где в первом случае БД были на одном разделе с другими данными, в т.ч. системой, как в отдельном подтоме, так и нет, во втором — на отдельном разделе. На общем разделе была огромная (более чем в 10 раз) просадка производительности по сравнению с другими ФС, во втором случае просадка была совсем небольшой. Сейчас статью не получается найти заново.
К этому времени в связи с невозможностью нормально отбалансировать старый диск (HDD) уже решил все данные через btrfs send | btrfs receive перенести на второй диск такого же размера, затем отключив первый. Заодно решил вынести MySQL в отдельный раздел BTRFS. Стало работать намного быстрее.
Эта статья заставила задуматься: а как отследить, что именно записывает на диск btrfs и почему? Это, вероятно, поможет понять, почему такая просадка производительности при БД на одном разделе с системой.
Что-то многовато у вас всего записано. Да, FF любит гадить на диск (про это писали и давно). Но использование tmpfs для /tmp и перенос туда временных директорий для кэша браузеров облегчат жизнь вашему твердотельнику. Вот для примера статистика на моей домашней машине, при том, что время работы диска в 2+ раза больше вашего (комп ночью не выключается):

=== START OF INFORMATION SECTION ===
Model Family: Samsung based SSDs
Device Model: Samsung SSD 860 EVO 500GB
Serial Number: S3Z1NB0K316508K
LU WWN Device Id: 5 002538 e40207f83
Firmware Version: RVT01B6Q
User Capacity: 500,107,862,016 bytes [500 GB]
Sector Size: 512 bytes logical/physical
Rotation Rate: Solid State Device
Form Factor: 2.5 inches
Device is: In smartctl database [for details use: -P show]
ATA Version is: ACS-4 T13/BSR INCITS 529 revision 5
SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Wed Nov 20 00:18:17 2019 EET
SMART support is: Available — device has SMART capability.
SMART support is: Enabled

SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always — 0
9 Power_On_Hours 0x0032 097 097 000 Old_age Always — 11572
12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always — 248
177 Wear_Leveling_Count 0x0013 099 099 000 Pre-fail Always — 6
179 Used_Rsvd_Blk_Cnt_Tot 0x0013 100 100 010 Pre-fail Always — 0
181 Program_Fail_Cnt_Total 0x0032 100 100 010 Old_age Always — 0
182 Erase_Fail_Count_Total 0x0032 100 100 010 Old_age Always — 0
183 Runtime_Bad_Block 0x0013 100 100 010 Pre-fail Always — 0
187 Uncorrectable_Error_Cnt 0x0032 100 100 000 Old_age Always — 0
190 Airflow_Temperature_Cel 0x0032 045 028 000 Old_age Always — 55
195 ECC_Error_Rate 0x001a 200 200 000 Old_age Always — 0
199 CRC_Error_Count 0x003e 100 100 000 Old_age Always — 0
235 POR_Recovery_Count 0x0012 099 099 000 Old_age Always — 125
241 Total_LBAs_Written 0x0032 099 099 000 Old_age Always — 7291759803

— Всему «виной» одна строчка в fstab:

tmpfs /tmp tmpfs defaults,noatime,nosuid,nodev,mode=1777,size=8G 0 1

и в /tmp — директории кэша для браузеров (и Хрома и Фокса).

После этой статьи обнаружил, что из десятков вкладок в Firefox какие-то несколько постоянно писали что-то в sqlite с куками и примерно в то же время писали что-то UBO с uMatrix. А еще довольно много на диск пишет приложение на Electron.


Firefox решился установкой расширения-suspender'а, а electron был заменен менее функциональным аналогом на Qt.

btrace — специфическое ПО для btrfs? Не могу его в арч линуксе найти

Не ясны причины таких показателей, либо это как-то объясняется с точки зрения архитектуры ФС, либо это неправильные показания соответствующих утилит. Понятно, что CoW, процессы в фоне, но не в 32 раза же…
btrace показывает информацию, которое сообщает ядро для блочного устройства. Она должна быть точна.
Можно посмотреть количество записанной информации с момента загрузки системы вручную, через статистику в /sys/block/sd*/stat, но это не так удобно:
awk '{printf "Uptime read: %.3fMiB (%.1f%% I/Os merged) written: %.3f MiB (%.1f%% I/Os merged)\n", $3*512/1048576, $2/$1*100, $7*512/1048576, $6/$5*100}' /sys/block/sdb/stat

Нужно протестировать другую copy-on-write ФС — zfs.
ZFS работает в обход VFS и, возможно, других API, эти утилиты отработают правильно?
Статистика блочного устройства (btrace) должна считаться правильно, fatrace тоже должен работать, т.к. использует inotify. Насчет iotop — не знаю.
С момента загрузки? Какие-то у меня на XFS дикие цифры выходят. 200Гб за 21 минуту:
alekciy@alekciy-myplaycity:~$ uptime 
 10:55:17 up 21 min,  1 user,  load average: 0,72, 0,41, 0,29
alekciy@alekciy-myplaycity:~$ awk '{printf "Uptime read: %.3fMiB (%.1f%% I/Os merged) written: %.3f MiB (%.1f%% I/Os merged)\n", $3*512/1048576, $2/$1*100, $7*512/1048576, $6/$5*100}' /sys/block/sda/stat
Uptime read: 1732.387MiB (0.4% I/Os merged) written: 200141.217 MiB (31.4% I/Os merged)
Сомнительное «ускорение» работы.
Сколько ОЗУ в системе?

Ага. Это все равно, что купить автомобиль бизнес-класса, но не ездить на нём, потому что жалко. Или купать чайный сервис и поставить его за стекло, а не пользоваться им — вдруг разобьют? Или купить одежду для ребёнка, но не разрешать в ней ходить — вдруг запачкает?

Нет, спасибо. У меня уже умер один ssd за две недели. (А потом второй, m2) Я не настолько богат.
1. Будет ли эта статья на английском?
Весьма нужна.

2. Что можете сказать о ZFS — так же себя ведёт?
На FreeBSD зачастую доступна только она
Only those users with full accounts are able to leave comments. Log in, please.