Комментарии 90
У самого на днях система на RPi не поднялась после перезагрузки. Всего одна новая программа за две недели убила microSD, которая до этого стабильно работала около 2-х лет.
По теме на хабре есть большая статья с не менее большими комментариями — «Малиновый Прог против Интернета Кирпичей, или Raspberry Pi с графикой на read-only microSD»
По теме на хабре есть большая статья с не менее большими комментариями — «Малиновый Прог против Интернета Кирпичей, или Raspberry Pi с графикой на read-only microSD»
Иногда read-only-система неудобна или нецелесообразна на одноплатниках, в этом случае описанные действия позволят выявить и отключить лишнее. Также, например, Libre Computer предоставляет образы ОС в btrfs в качестве основной файловой системы, и я до анализа её поведения на своем компьютере и написания этой статьи не знал, что усиление записи настолько сильное.
Статья несомненно полезна, но Вы меня конечно простите, но вы какие-то странные ребята, я про автора статьи, который цитирует рекомендации по переносу профиля на hdd чтобы меньше писать на ssd и пожертвовать скоростью ради сохранности ssd.
Для чего я покупаю SSD? В первую очередь для того чтобы быстро на него писать данные и еще быстрее читать эти данные, и мне пофиг будет ли на ssd профиль гуглохрома или еще какой-то программы которая будет насиловать диск, главное что эти программы работают быстро — что мне и нужно.
Берите дешевые ssd, размещайте на них только ОС, а критически важные данные храните на hdd ну и конечно делайте бэкапы.
Я раз в месяц снимаю с ssd где стоит ос образ и если он умрет я без сожаления его выкину, пойду и куплю новый ssd за 3 т.р., разверну образ ОС за 10 минут и продолжу работать. А заниматься ерундой по вычислению сколько какая программа пишет — увольте.
Для чего я покупаю SSD? В первую очередь для того чтобы быстро на него писать данные и еще быстрее читать эти данные, и мне пофиг будет ли на ssd профиль гуглохрома или еще какой-то программы которая будет насиловать диск, главное что эти программы работают быстро — что мне и нужно.
Берите дешевые ssd, размещайте на них только ОС, а критически важные данные храните на hdd ну и конечно делайте бэкапы.
Я раз в месяц снимаю с ssd где стоит ос образ и если он умрет я без сожаления его выкину, пойду и куплю новый ssd за 3 т.р., разверну образ ОС за 10 минут и продолжу работать. А заниматься ерундой по вычислению сколько какая программа пишет — увольте.
За 6 лет это у меня уже третий SSD, т.е. SSD в моем ноутбуке в среднем нормально работает 2 года, заметьте, с учетом того, что большая часть часто изменяющихся данных находится на HDD. Это очень мало, аномально мало, поэтому я и начал разбираться. Если бы SSD не выходили из строя, а работали так, как обычно пишут комментирующие, я бы не заморачивался, и не узнал об огромном коэффициенте увеличения записи в btrfs. А ведь её люди и на MicroSD используют.
arstechnica.com/information-technology/2016/11/for-five-months-spotify-has-badly-abused-users-storage-drives
А заниматься ерундой по вычислению сколько какая программа пишет — увольте.Статья также полезна для выявления значительных проблем ПО. Например, в 2016 году Spotify очень часто выполнял команду VACUUM на sqlite-базе, что приводило к записи до 700 ГБ в сутки на диск. Один такой Spotify, и гарантия на ваш диск истечет через полгода после покупки. Программа неправильно работала в течение 5 месяцев.
arstechnica.com/information-technology/2016/11/for-five-months-spotify-has-badly-abused-users-storage-drives
НЛО прилетело и опубликовало эту надпись здесь
Наверное и SSD у вас на SLC или MLC, сейчас подавляющее большинство дисков это TLC или QLC, ресурс у них в стони и тысячи раз меньше
Дак не используйте btrfs. В чем ее плюсы для домашнего использования? Скорость? Надежность? А, что классика ext4 уже для дома не надежна или медлительна? Нет. Дак в чем профит? Но все равно мыши плакали, кололись, но продолжали использовать btrfs.
А может у Вас старая версия ядра и btrfs? Посмотрите тут и сравните с тем что у Вас. А еще прочитайте про профиль хранения данных в btrfs (при создании раздела SSD detected было yes ?) и вот это в официальном FAQ
Ну и самое главное — зная архитектуру btrfs (хорошая статья):
Можно сделать вывод, что «насиловать» SSD она будет всегда, остается лишь поднастроить ее, чтобы это было в пределах нормы.
Ну и каждые 2 года новый SSD — конечно маловато, но один то SSD у вас по вине контроллера умер, то есть это был скорее всего брак и если исходить из отсутствия брака, то получается каждые 3 года новый SSD — по-моему вполне нормально, если Вы не будите покупать супер-дорогие, а остановитесь на дешевых.
А может у Вас старая версия ядра и btrfs? Посмотрите тут и сравните с тем что у Вас. А еще прочитайте про профиль хранения данных в btrfs (при создании раздела SSD detected было yes ?) и вот это в официальном FAQ
Ну и самое главное — зная архитектуру btrfs (хорошая статья):
К сожалению, btrfs «благодаря» своей архитектуре крайне подвержена такому явлению, как фрагментация. Дело в том, что данные записываются всегда в новое расположение на диске. Даже если прочитать файл, ничего не сделать с данными и записать их обратно в тот же файл, то данные попадут на диске в новую область. То же самое произойдет, если обновить данные в файле только частично — изменения запишутся в новую область на диске.
Можно сделать вывод, что «насиловать» SSD она будет всегда, остается лишь поднастроить ее, чтобы это было в пределах нормы.
Ну и каждые 2 года новый SSD — конечно маловато, но один то SSD у вас по вине контроллера умер, то есть это был скорее всего брак и если исходить из отсутствия брака, то получается каждые 3 года новый SSD — по-моему вполне нормально, если Вы не будите покупать супер-дорогие, а остановитесь на дешевых.
НЛО прилетело и опубликовало эту надпись здесь
А ext4 с lvm этого уже не умеют?
Поддержу.
У меня настроено автоматическое создание снепшотов через cron. И удаление их через 14 дней.
Очень удобно. За считанные секунды откатиться на любую дату, а потом обратно.
SSD у меня родной в MacBook Pro 2013 года.
Соответственно ему 6 лет. И SWAP, и профиль, и виртуальные машины — все на нем.
Никаких проблем не наблюдается…
С HDD использовать такую схему не настолько комфортно. Там приходится делать принудительную дефрагментацию, минимум раз в 3 месяца. Иначе начинаются «залипания» по несколько секунд. Во время дефрагментации производительность диска падает практически до нуля.
Но если настроить авто дефрагментацию в период минимальной нагрузки — вполне можно жить.
У меня настроено автоматическое создание снепшотов через cron. И удаление их через 14 дней.
Очень удобно. За считанные секунды откатиться на любую дату, а потом обратно.
SSD у меня родной в MacBook Pro 2013 года.
Соответственно ему 6 лет. И SWAP, и профиль, и виртуальные машины — все на нем.
Никаких проблем не наблюдается…
С HDD использовать такую схему не настолько комфортно. Там приходится делать принудительную дефрагментацию, минимум раз в 3 месяца. Иначе начинаются «залипания» по несколько секунд. Во время дефрагментации производительность диска падает практически до нуля.
Но если настроить авто дефрагментацию в период минимальной нагрузки — вполне можно жить.
Дак не используйте btrfs. В чем ее плюсы для домашнего использования? Скорость? Надежность? А, что классика ext4 уже для дома не надежна или медлительна? Нет. Дак в чем профит? Но все равно мыши плакали, кололись, но продолжали использовать btrfs.Раньше я везде использовал только ext4, но в Fedora btrfs предлагается по умолчанию, и я решил использовать её. В btrfs очень удобная функциональность снапшотов. Понятно, что можно использовать ext4 на lvm, но btrfs просто удобней, хотя бы в силу того, что я несколько раз создавал ФС с не очень большим количеством inode, а потом не мог распаковать что-то большое на ФС.
Версия ядра у меня одна из самых новых, это же Fedora.
НЛО прилетело и опубликовало эту надпись здесь
Для SSD эта проблема также актуальна, но не так сильно выражена, как для HDD. SSD может обеспечивать, скажем, 3200 МБ/с линейного чтения и 40 МБ/с случайного, а HDD — 250 МБ/с линейного и 1 МБ/с случайного.
НЛО прилетело и опубликовало эту надпись здесь
Посмотрите любой тест SSD на случайное чтение. Обычно тестируют случайное чтение блоками по 4 КБ, что мало для реальных ФС, но кое-какое представление о разнице в скорости между линейным и случайным чтением, а следовательно, о воздействии фрагментации дать может.
Если интересно, вот что сходу нашлось: www.overclock.net/forum/355-ssd/1538878-yes-file-system-fragmentation-does-affect-ssd-read-speed.html
НЛО прилетело и опубликовало эту надпись здесь
Еще бы хотел добавить, что запись всегда в новое место естественным образом реализует выравнивание износа ячеек. Что для твердотельного накопителя плюс.
Глупость. В SSD используется таблица трансляции, контроллер каждый раз пишет данные в новое место.
Я лично не встречался, но много раз слышал как флешки быстро умирали при использовании журналируемых ФС
А вот во флешках контроллер тупой.
Ведь для SSD эта проблема неактуальна
Ещё как актуальна, и связано это, в первую очередь, с износом ячеек, а не со скоростью.
Дело в том, что нельзя просто взять и записать новые данные поверх старых. Нужно считать данные, полностью стереть ячейку (а это около 512кб), а потом их записать обратно с изменениями.
В случае последовательной записи маленькими фрагментами контроллер имеет возможность консолидировать данные и обойтись одной перезаписью, но в случае рандомной записи придётся перезаписывать ячейку на каждый чих. Потому это и приводит к высокому Write Amplification.
контроллеру SSD совершенно пофиг, что вы считате рандомной записью, а что последовательной
он забирает из буфера данные, записывает их туда, куда считает нужным и сохраняет операцию у себя в табличке
когда кончаются тримнутые ячейки — да, производительность деградирует, ну так и это тоже забота контроллера, следить, чтобы запас был, а если он не успевает, значит вы выбрали неподходящую для вашей задачи модель
он забирает из буфера данные, записывает их туда, куда считает нужным и сохраняет операцию у себя в табличке
когда кончаются тримнутые ячейки — да, производительность деградирует, ну так и это тоже забота контроллера, следить, чтобы запас был, а если он не успевает, значит вы выбрали неподходящую для вашей задачи модель
контроллеру SSD совершенно пофиг, что вы считате рандомной записью, а что последовательной
Если бы ему было пофиг, то в тестах на скорость записи/чтения не было бы разницы между случайной и последовательной записью.
он забирает из буфера данные, записывает их туда, куда считает нужным и сохраняет операцию у себя в табличке
Контроллер оперирует на уровне блоков флеш-памяти — вот их он и может тасовать как ему вздумается, при этом деградации вскорости не будет.
когда кончаются тримнутые ячейки — да, производительность деградирует, ну так и это тоже забота контроллера, следить, чтобы запас был, а если он не успевает, значит вы выбрали неподходящую для вашей задачи модель
Это не забота контроллера, а забота драйвера файловой системы. Контроллер никак не может узнать, свободна ли ячейка или нет, пока вы ему не скажете об этом явно.
Если бы ему было пофиг, то в тестах на скорость записи/чтения не было бы разницы между случайной и последовательной записью.
ну да, не совсем пофиг, внутренний конвейер же тоже страдает, ок
Контроллер оперирует на уровне блоков флеш-памяти — вот их он и может тасовать как ему вздумается, при этом деградации вскорости не будет.
не совсем так, очищен может быть только блок целиком, оперирует контроллер всё-таки традиционными страницами
Контроллер никак не может узнать, свободна ли ячейка или нет, пока вы ему не скажете об этом явно
эмм, так-то контроллер их записывает, читает и удаляет, он обязан знать, где свободные ячейки, а где занятые
ОС вообще не в курсе про этот низкий уровень, для неё любой накопитель выглядит, как набор LBA
не совсем так, очищен может быть только блок целиком, оперирует контроллер всё-таки традиционными страницами
Да, это так. Дописать страницу в свободную часть блока — легко, прочитать страницу — легко. Но перезаписать страницу — тяжело, нужна полная очистка блока.
Плюс последовательно идущие логические страницы в итоге все равно должны быть записаны в один блок, иначе будет дико страдать производительность в том числе и на чтение из-за большого количества уровней индирекции.
эмм, так-то контроллер их записывает, читает и удаляет, он обязан знать, где свободные ячейки, а где занятые
ОС вообще не в курсе про этот низкий уровень, для неё любой накопитель выглядит, как набор LBA
Так ОС явно и говорит, что надо почистить. Конечно, есть модели SSD, где физически ячеек больше, чем доступно ОС, этот объём и используется контроллеров для собственных нужд.
Не могли бы вы указать на конкретные модели ssd, которые вы использовали?
вот это цифры… прочитав статью, судорожно полез на свой сервак, в который впихнул 860-ю прошку от самсунга. (они обещают 600 tbw для моего размера — тоже как-то «подозрительно вечный» диск, ну, под мои нужды, конечно)
За 6 месяцев — 6 с небольшим терабайт и это сборочный сервак (ci) в отделе из 10 человек, а в статье ноут в монопольном доступе для одного человека — почти 20 тб за 7 месяцев… чудесато…
За 6 месяцев — 6 с небольшим терабайт и это сборочный сервак (ci) в отделе из 10 человек, а в статье ноут в монопольном доступе для одного человека — почти 20 тб за 7 месяцев… чудесато…
Когда-то, в 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 использовали неверную методику.
В их "методике" бывают проверки смарт атрибутов и вычисление фактического коэффициента усиления записи на их тесте. Достаточно ли поделить обнаруженный 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 исчерпал свой ресурс до окончания гарантии — то разве его по гарантии не заменить?
> За 6 лет это у меня уже третий SSD, т.е. SSD в моем ноутбуке в среднем нормально работает 2 года
Это странно. Использую btrfs везде, в т.ч. на microsd, emmc, флешках с 2011/2012 года (точно не помню) за это время заподозрить btrfs я могу разве что в отношении переставшего загружаться DEXP Ursus 7W (зависание на лого BIOS, перед запуском GRUB2) и то не факт что там запилена emmc, а не просто китайский планшет накрылся. Все остальные накопители (среди которых десятки SSD) в том числе мой самый первый SSD (Crucial M500, если не изменяет память) до сих пор живы и здоровы.
На мой взгляд вам стоит искать причину неисправности этих SSD не в файловой системе.
Это странно. Использую btrfs везде, в т.ч. на microsd, emmc, флешках с 2011/2012 года (точно не помню) за это время заподозрить btrfs я могу разве что в отношении переставшего загружаться DEXP Ursus 7W (зависание на лого BIOS, перед запуском GRUB2) и то не факт что там запилена emmc, а не просто китайский планшет накрылся. Все остальные накопители (среди которых десятки SSD) в том числе мой самый первый SSD (Crucial M500, если не изменяет память) до сих пор живы и здоровы.
На мой взгляд вам стоит искать причину неисправности этих SSD не в файловой системе.
Я только page перенес на хард, но это Винда 7.
> Вывод: не стоит использовать btrfs, если программы часто записывают небольшое количество данных (несколько килобайт)
Одна из ключевых фишек Btrfs — поддержка сжатия на лету (zstd, zlib, lz4). Естественно, далеко не все данные хорошо сжимаются, но некоторые ужимаются очень хорошо, как известно. Так что каковы, в таком случае, будут значения коэффициента усиления записи — вопрос открытый. Понятно, что на размерах в несколько килобайт (то есть одна-две 4k-страницы) вряд ли что-то сильно поменяется, но есть и другие шаблоны записи на диск, естественно. Будет ли в итоге выигрыш, или же нет — вопрос мало того, что открытый, так еще и несколько индивидуальный.
Кроме того, нужно помнить, что Btrfs — использует парадигму Copy-on-Write, что подразумевает лучшее распределение записи по всему объему, а не перезапись in place.
Одна из ключевых фишек Btrfs — поддержка сжатия на лету (zstd, zlib, lz4). Естественно, далеко не все данные хорошо сжимаются, но некоторые ужимаются очень хорошо, как известно. Так что каковы, в таком случае, будут значения коэффициента усиления записи — вопрос открытый. Понятно, что на размерах в несколько килобайт (то есть одна-две 4k-страницы) вряд ли что-то сильно поменяется, но есть и другие шаблоны записи на диск, естественно. Будет ли в итоге выигрыш, или же нет — вопрос мало того, что открытый, так еще и несколько индивидуальный.
Кроме того, нужно помнить, что Btrfs — использует парадигму Copy-on-Write, что подразумевает лучшее распределение записи по всему объему, а не перезапись in place.
НЛО прилетело и опубликовало эту надпись здесь
> Этим, вообще-то, контроллер SSD занимается
1. Использование «вообще-то»какБыНамекает™ звучит так, что информация выше неверна. А это не так.
2. Чем занимается отдельно-взятый контроллер (ресурсы которого, по сравнению с системными, довольно скромные), как правило, известно мало. На Github'е их как-то не много. :) Кроме того, там бывают баги, и даже обновления прошивок, которые, естественно устанавливаются далеко не всеми, и не всегда. Другими словами — шансы получить обновление, на уровне OS, существенно выше, чем на уровне контроллера.
3. Как известно, зачастую трансляция одной парадигмы в другую — менее эффективна, чем изначальное следование целевой. Именно по этой причине для SSD (и прочих накопителей схожих принципов) разрабатываются специализированные файловые системы (например JFFS2), где wear-levelling, опять же, является изначальным свойством самой FS.
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
При чтении/записи SSD оперируют страницами, а не секторами, размер страницы может быть от 2 до 16 кб (зависит от конкретной модели), соответственно запись 1 байта никак не может занять меньше 2K в лучшем случае.
Ситуация ухудшается если вам нужно не записать а изменить 1 байт — сначала он прочитает страницу с этим байтом, поменяет в прочитанном блоке этот самый байт, а потом пойдёт искать пустую страницу в которую его можно записать, отметив старую как «грязную» (т.е. использованную но не доступную для записи).
Всё усложняется тем что хоть писать и можно на уровне страницы, запись не может быть сделана «поверх» — сначала нужно стереть аж целый блок (состоящий из многих страниц, от 256K до 4M), и только потом писать.
Если пустых страниц нет (диск был записан полностью как минимум один раз, при этом TRIM не использовался — частый случай когда SSD используются в RAID), то всё просто кошмарно — контроллер сначала читает весь блок, где находится тот злосчастный байт, читает его весь (да, до 4M), стирает его и перезаписывает полностью. На самом деле чуть сложнее — он может попытаться начать джонглировать блоками в рамках оптимизации износа и сборки мусора, ища то что реже всего стиралось и перетасовывая найденное в процессе, вовлекая в процесс резервную зону (недоступную для обычного использования).
Разумеется, всё это дорого обходится — производительность падает, и чем дальше тем больше. TRIM помогает сильно улучшить ситуацию, но, как я уже сказал раньше, не все RAID контроллеры его поддерживают (увы), хотя для «домашних» применений (нет RAID и система поддерживает TRIM) всё достаточно неплохо (если диск под завязку не забит).
Ситуация ухудшается если вам нужно не записать а изменить 1 байт — сначала он прочитает страницу с этим байтом, поменяет в прочитанном блоке этот самый байт, а потом пойдёт искать пустую страницу в которую его можно записать, отметив старую как «грязную» (т.е. использованную но не доступную для записи).
Всё усложняется тем что хоть писать и можно на уровне страницы, запись не может быть сделана «поверх» — сначала нужно стереть аж целый блок (состоящий из многих страниц, от 256K до 4M), и только потом писать.
Если пустых страниц нет (диск был записан полностью как минимум один раз, при этом TRIM не использовался — частый случай когда SSD используются в RAID), то всё просто кошмарно — контроллер сначала читает весь блок, где находится тот злосчастный байт, читает его весь (да, до 4M), стирает его и перезаписывает полностью. На самом деле чуть сложнее — он может попытаться начать джонглировать блоками в рамках оптимизации износа и сборки мусора, ища то что реже всего стиралось и перетасовывая найденное в процессе, вовлекая в процесс резервную зону (недоступную для обычного использования).
Разумеется, всё это дорого обходится — производительность падает, и чем дальше тем больше. TRIM помогает сильно улучшить ситуацию, но, как я уже сказал раньше, не все RAID контроллеры его поддерживают (увы), хотя для «домашних» применений (нет RAID и система поддерживает TRIM) всё достаточно неплохо (если диск под завязку не забит).
Статья отличная, но многие читатели спросят:
Почему мой SSD по формуле
Что получается очень мало для активного в работе диска
38360 × 512 ÷ 1000 ÷ 1000 ÷ 1000 ÷ 1000 = 0.00001964032 ТБ
На самом деле если обновить базу smartctl
параметр 241 превращается… в Host_Writes_32MiB
И умножать надо на 32MiB, а не 512 байт.
Почему мой 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 байт.
/usr/sbin/update-smart-drivedb
Но на новых системах после обсуждения
bugs.debian.org/cgi-bin/bugreport.cgi?bug=804299
Такую прекрасную возможность убрали.
Поэтому если в 241 слишком маленькое значение, умножайте его на 32MiB вместо 512 байт.
Есть ещё такой запрос: 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 ... и потом посмотреть в мане, как получить самое интересное без лишней портянки.
Удалено
А для zfs кто-то замерял?
Намучался отучая просыпаться диск на сервере, дольше всего пришлось перепиливать пути для самбы.
Насколько я знаю, очень сильно зависит от диска. Я бы не стал покупать самые дешевые диски просто потому, что экономия будет небольшая, а, скорее всего, сделано сильное упрощение.
На хороших дисках запись не должна напрямую вести к записи в ячейку, данные должны накапливаться в оперативной памяти и записываться по мере заполнения. Конечно, усиление записи приведет к увеличению общего количества записанных данных, но от него срок службы не зависит линейно.
Вторая вещь на что смотреть — размер overprovisioning области. Эта область (как и TRIM) может помочь диску писать намного меньше в ячейки. Некоторые диски позволяют выделять эту область в процентном выражении при помощи утилит. Еще есть вариант сделать secure erase и потом разметить разделы меньше, чем размер диска. Т.о. дать диску возможность использовать эту область для перераспределения данных. Мне кажется, такое сильно поможет особенно в случаях, когда диск под завязку уже записан.
Для MicroSD это вряд ли поможет, не знаю что там.
По поводу надежности. По сути, при правильных расчетных параметрах SSD по моему предположению должны были бы быть такие же надежные как и оперативка. В реальности, по моему опыту, в сотнях новых серверов с SSD (хорошего бренда) обычно 5-10 дисков могут не работать прямо с самого начала или получить сбой почти сразу. Далее диски вылетают реже, чем HDD, но намного более часто, чем RAM и достаточно случайным образом.
На хороших дисках запись не должна напрямую вести к записи в ячейку, данные должны накапливаться в оперативной памяти и записываться по мере заполнения. Конечно, усиление записи приведет к увеличению общего количества записанных данных, но от него срок службы не зависит линейно.
Вторая вещь на что смотреть — размер overprovisioning области. Эта область (как и TRIM) может помочь диску писать намного меньше в ячейки. Некоторые диски позволяют выделять эту область в процентном выражении при помощи утилит. Еще есть вариант сделать secure erase и потом разметить разделы меньше, чем размер диска. Т.о. дать диску возможность использовать эту область для перераспределения данных. Мне кажется, такое сильно поможет особенно в случаях, когда диск под завязку уже записан.
Для MicroSD это вряд ли поможет, не знаю что там.
По поводу надежности. По сути, при правильных расчетных параметрах SSD по моему предположению должны были бы быть такие же надежные как и оперативка. В реальности, по моему опыту, в сотнях новых серверов с SSD (хорошего бренда) обычно 5-10 дисков могут не работать прямо с самого начала или получить сбой почти сразу. Далее диски вылетают реже, чем HDD, но намного более часто, чем RAM и достаточно случайным образом.
Недавно надоел жутко высокий Load Average и очень низкая скорость работы MySQL на BTRFS с CoW. btrfs balance работал сутками, доводил сервер до почти неотзывчивого состояния и никак не мог завершиться. И это при том, что с самого начала использовал btrfsmaintenance для регулярных автоматических балансировок.
Нашел статью человека, который сравнил производительность MySQL на BTRFS, где в первом случае БД были на одном разделе с другими данными, в т.ч. системой, как в отдельном подтоме, так и нет, во втором — на отдельном разделе. На общем разделе была огромная (более чем в 10 раз) просадка производительности по сравнению с другими ФС, во втором случае просадка была совсем небольшой. Сейчас статью не получается найти заново.
К этому времени в связи с невозможностью нормально отбалансировать старый диск (HDD) уже решил все данные через
Эта статья заставила задуматься: а как отследить, что именно записывает на диск btrfs и почему? Это, вероятно, поможет понять, почему такая просадка производительности при БД на одном разделе с системой.
Нашел статью человека, который сравнил производительность 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 — директории кэша для браузеров (и Хрома и Фокса).
=== 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.
А есть способ узнать какой sql запрос делает Group Speed Dial каждые 30 сек?
НЛО прилетело и опубликовало эту надпись здесь
Не ясны причины таких показателей, либо это как-то объясняется с точки зрения архитектуры ФС, либо это неправильные показания соответствующих утилит. Понятно, что CoW, процессы в фоне, но не в 32 раза же…
btrace показывает информацию, которое сообщает ядро для блочного устройства. Она должна быть точна.
Можно посмотреть количество записанной информации с момента загрузки системы вручную, через статистику в /sys/block/sd*/stat, но это не так удобно:
Нужно протестировать другую copy-on-write ФС — zfs.
Можно посмотреть количество записанной информации с момента загрузки системы вручную, через статистику в /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, эти утилиты отработают правильно?
С момента загрузки? Какие-то у меня на 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)
Вот поэтому у меня swap уехал на hdd.
Сомнительное «ускорение» работы.
Сколько ОЗУ в системе?
Сколько ОЗУ в системе?
Ага. Это все равно, что купить автомобиль бизнес-класса, но не ездить на нём, потому что жалко. Или купать чайный сервис и поставить его за стекло, а не пользоваться им — вдруг разобьют? Или купить одежду для ребёнка, но не разрешать в ней ходить — вдруг запачкает?
1. Будет ли эта статья на английском?
Весьма нужна.
2. Что можете сказать о ZFS — так же себя ведёт?
На FreeBSD зачастую доступна только она
Весьма нужна.
2. Что можете сказать о ZFS — так же себя ведёт?
На FreeBSD зачастую доступна только она
В дистрибутиве unRAID Docker-контейнеры хранятся в loop-файле на BTRFS, без noatime, на порядок усиливая запись: 141 ТБ за 296 дней.
forums.unraid.net/bug-reports/stable-releases/683-docker-image-huge-amount-of-unnecessary-writes-on-cache-r733/?do=findComment&comment=11233
forums.unraid.net/bug-reports/stable-releases/683-docker-image-huge-amount-of-unnecessary-writes-on-cache-r733/?do=findComment&comment=11233
По умолчанию Firefox сохраняет всю сессию каждые 3 мин. даже если просто скролить один сайт. Сделано чтобы в случае краша можно было восстановиться. (При нормальном выходе сохраняется всегда если включено восстановление сессии.)
За это отвечает параметр:
browser.sessionstore.interval - интервал сохранения (значение в мс)
browser.sessionstore.interval.idle - как часто сохранять сессию в режиме бездействия, например когда окно свернуто
browser.sessionstore.idleDelay - как скоро переходить в режим бездействия
Если браузер не падает часто полезно увеличить значения
nice post, thanks for that. I'll try to keep myself away from btfs :)
During my own experiments I found fatrace as the most usable, because it's the only one you can limit to look after a specific mount.
Like in my case I do have zram mounted as /tmp /var/tmp (and few other mounts like that) so I don't care if it's being raped by continuous writes. But I do care if some unexpected piece of s...oftware start raping my precious SD card which is mounted to / :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Выявляем процессы с дисковой активностью в Linux