Комментарии 205
НЛО прилетело и опубликовало эту надпись здесь
всего два месяца?? я даже не подозревал, что всё настолько фигово, добавлю-ка пункт в голосовалку
Эх малинку не имею и никогда не трогал, но кажется теперь я понял почему у меня в телефоне карта стала readonly после того как создал на ней раздел ext и смонтировал для установки программ. Продержалась кстати тоже около 2-3 месяцев. Как раз думал на тему износа по циклам записи, но гугл при поиске убедил меня, что износ — прерогатива usb flash, а на microsd еще никто не сталкивался. Рад что мое предположение оказалось верным. Теперь интересно стало сколько же андроид дергает фс в течении месяца/года и на сколько же хватит встроенной памяти в телефоне.
У меня жили по 2-3 месяца, даже без граф.обоочек.
С readonly-root живут на улице уже более года, некоторые станции слеланы на «малине» — http://meteo38.ru/
С readonly-root живут на улице уже более года, некоторые станции слеланы на «малине» — http://meteo38.ru/
Вот оно что, а я думал что это упавшее питание убивает карточки, и волосы на голове рвал с чего бы это.
Т.е. работает оно пару месяцев, все ок, может какие-то проблемы пошли, но ОС загружена, а после выключения уже не поднимается. И естественно думал что раз выключение питания убивает карту, то никакое readonly не поможет. Никогда не знаешь каким боком баг вылезет.
Т.е. работает оно пару месяцев, все ок, может какие-то проблемы пошли, но ОС загружена, а после выключения уже не поднимается. И естественно думал что раз выключение питания убивает карту, то никакое readonly не поможет. Никогда не знаешь каким боком баг вылезет.
Я так представляю процесс: размер записываемого блока 512 байт кратно меньше страницы NAND-памяти, которую микроконтроллер флэшки вынужден сперва «взять» целиком, заменить в ней эти 512 байт, после чего «пристроить» на новое место (всё происходит внутри флэшки, драйвер файловой системы ничего этого не видит). Причём сперва это новое место нужно ещё найти и очистить током (flash erase).
Сбой питания вряд ли убьёт карточку, но может не дать закончиться транзакции записи, о чём драйвер файловой системы так и не узнает. Вероятность «битой» транзакции зависит ещё и от того, насколько хорошо сделана прошивка микроконтроллера флэшки. У контрафактных продуктов с китайских онлайн-площадокв качестве вместо «мозгов» может быть вообще всё, что угодно, включая черновые варианты украденных исходных кодов, примеры из поставок профессиональных средств для разработчиков (тоже украденных) и т.д. Это целый мир, скрытый в маленьком кусочке пластика.
Поэтому с точки зрения сбоя питания регулярная запись на флэшку резко увеличивает вероятность непокрываемой журналом файловой системы потери данных, однако не делает эту вероятность 100%. Но даже если карточка по-честному произведена, например, SanDisk, и имеет идеальные мозги, остаётся неконтролируемый электрический износ, который пока можно отслеживать только вручную (я поместил пару простых команд Linux в публикацию). Ждём новые отраслевые стандарты и аналоги HDD SMART для Интернета Вещей.
Переход на read-only должен решать обе проблемы: при отсутствии записи не должно быть ни электрического износа NAND-памяти, ни «битых» транзакций. И даже на контрафактных носителях система будет себя вести гораздо стабильнее, но всё равно недолго:)
Сбой питания вряд ли убьёт карточку, но может не дать закончиться транзакции записи, о чём драйвер файловой системы так и не узнает. Вероятность «битой» транзакции зависит ещё и от того, насколько хорошо сделана прошивка микроконтроллера флэшки. У контрафактных продуктов с китайских онлайн-площадок
Поэтому с точки зрения сбоя питания регулярная запись на флэшку резко увеличивает вероятность непокрываемой журналом файловой системы потери данных, однако не делает эту вероятность 100%. Но даже если карточка по-честному произведена, например, SanDisk, и имеет идеальные мозги, остаётся неконтролируемый электрический износ, который пока можно отслеживать только вручную (я поместил пару простых команд Linux в публикацию). Ждём новые отраслевые стандарты и аналоги HDD SMART для Интернета Вещей.
Переход на read-only должен решать обе проблемы: при отсутствии записи не должно быть ни электрического износа NAND-памяти, ни «битых» транзакций. И даже на контрафактных носителях система будет себя вести гораздо стабильнее, но всё равно недолго:)
Не знаю как для Raspberry Pi, а для микроконтроллеров проблема закрытия транзакции записи в flash-память решается например так: Детектор питания настраивается на такой порог, ниже которого в норме напряжение не должно опускаться, но при котором МК и флешка ещё должны нормально работать. Перед началом транзакции записи проверяется, не вышло ли питание за этот порог, и если вышло — начало записи откладывается до нормализации питания. При этом до завершение транзакции записи питание обеспечивается конденсаторами на плате. Если встроенного детектора нет (а в STM32 он есть) — используется внешняя микросхема монитора питания, обычно с жестко заданным порогом. Возможно в Raspberry Pi есть такой детектор? С SD-картами по-моему всё несколько сложнее чем с SPI-флешками — у них похоже есть внутренний кэш страницы с задержанной записью. Причём в тех открытых версиях стандарта, что мне попадались, команда принудительной выгрузки кэша не описаны, но она должна существовать, и её нужно выдавать при просадке питания.
благодарю, неплохо описано; я так понимаю, на рынке МК описанные внутренности просто must have, чтобы этот рынок не прое#@ть :)
пока же у меня создалось ощущение, что на рынке любительских платформ для Вещей дела обстоят по-детски наивно; а что там с питанием SD-ридера в МалинПроге, я даже боюсь подумать
пока же у меня создалось ощущение, что на рынке любительских платформ для Вещей дела обстоят по-детски наивно; а что там с питанием SD-ридера в МалинПроге, я даже боюсь подумать
Так это относится к питанию изделия в целом. В той же Pi в цепи питания наверняка есть конденсаторы, а если нет — их можно добавить.
В худшем случае, если нет возможности измерить напряжение на входе, можно поставить там компаратор с выходом на одну из ног GPIO: как только напряжение упадёт, ОС получит сигнал, на который отреагирует командой sync && mount / -o remount,ro.
В худшем случае, если нет возможности измерить напряжение на входе, можно поставить там компаратор с выходом на одну из ног GPIO: как только напряжение упадёт, ОС получит сигнал, на который отреагирует командой sync && mount / -o remount,ro.
Жирный понадобится конденсатор, возможно даже Li-Ion, с учетом медлительности RP и потребления почти 5Вт.
Всё так. Только мониторить питание лучше на ступень выше. Например если устройство питается от 5В, а далее стоит LDO на 3.3В, то мониторить надо 5В. Встроенного АЦП для этого как правило предостаточно.
Только по спекам SD флэшка может тупить аж целых 0,5 сек. Много надо конденсаторов. И случаются эти затупы достаточно рандомно.
Кстати в MicroSD карте есть огромный конденсатор (по меньшей мере десятки микрофарад). Попробуйте воткнуть карту во включенное устройство, со слабым питанием и без фильтра на питании SD с осциллографом на питании МК.
С SD-картами по-моему всё несколько сложнее чем с SPI-флешками
Три раза прочитал пока понял о чем речь. Обычная SD тоже умеет в SPI.
Сильно поношенные и из неудачных серий SD флэшки могут писать один блок много раз, пока не запишут удачно.
Когда я писал про SPI-флешки — я имел в виду запаиваемые микросхемы флэш-памяти объёмом в несколько мегабайт с интерфейсом SPI или QSPI, например, от Atmel серии AT45 или от Winbond W25Q64JV. В отличие от SD-карт они есть во всех наших устройствах на микроконтроллерах STM32, потому что микроконтроллеры F, Н и G серий не имеют удобной для работы внутренней памяти данных. У них время записи гораздо меньше, чем у SD-карт, поэтому порог можно использовать близкий к минимальному рабочему напряжению. А 5 вольт в устройствах часто вообще нет. По стандарту SD-карта может писать до 500 мс, но в реальности я такого никогда не видел — видел от 15 до 110 мс для разных карт. А SPI обязателен только для SD, для SDHC его наличие — на усмотрение производителя. Если речь идёт о защите от отключения первичного питания — мы используем пороговый детектор в цепи первичного питания 12..72В, подключенный через оптрон. Но кроме того и встроенный детектор STM32. Пишет она столько тогда, когда для записи сектора ей нужно стереть страницу, которая имеет неизвестный микроконтроллеру размер.
Лет 8 назад развлекался с read-only centos для небольших телефонных станций на asterisk. Помню, что монтировалось в read-only и так же в памяти всякая временная хрень. Работали по года 2 без проблем. Использовался переходник с IDE на SD. Графики конечно не было никакой.
Но потанцевать с бубном много пришлось. Практически академию бубна закончил.
Но потанцевать с бубном много пришлось. Практически академию бубна закончил.
Наздоровье. Рад что пригодилось.
Кстати, нашел тут кое-что по поводу RAM disk-а для Pi: https://www.domoticz.com/wiki/Setting_up_a_RAM_drive_on_Raspberry_Pi
Люди запускают не инфотабло/слайдшоу а domoticz (решение для «умного дома»), но проблему решают ту же — смерть SD при продолжительном использовании. Правда не так радикально — в RAM диске всего одна папка.
Возможно есть вариант расширить это на home папку пользователя (а также и на swap и что там еще), и при старте заполнять ее заранее заготовленной копией с SD карты.
Люди запускают не инфотабло/слайдшоу а domoticz (решение для «умного дома»), но проблему решают ту же — смерть SD при продолжительном использовании. Правда не так радикально — в RAM диске всего одна папка.
Возможно есть вариант расширить это на home папку пользователя (а также и на swap и что там еще), и при старте заполнять ее заранее заготовленной копией с SD карты.
+ тема на форуме Распбери: https://www.raspberrypi.org/forums/viewtopic.php?f=37&t=63996
+ вариант переноса большей части FS на USB носитель (SD карта все равно требуется, т.к. Распбери загружается ислючительно с SD, но писать на SD он уже не будет, насколько я понял): http://www.instructables.com/id/Boot-the-Raspberry-Pi-from-USB/
+ вариант переноса большей части FS на USB носитель (SD карта все равно требуется, т.к. Распбери загружается ислючительно с SD, но писать на SD он уже не будет, насколько я понял): http://www.instructables.com/id/Boot-the-Raspberry-Pi-from-USB/
про swap шутка, видимо;)
Я на ночь глядя уже не соображу — вроде ж есть swap файл у raspbian: http://raspberrypi.stackexchange.com/questions/70/how-to-set-up-swap-space
P.S. Пишут что есть, включен по умолчанию
http://raspberrypimaker.com/adding-swap-to-the-raspberrypi/
P.S. Пишут что есть, включен по умолчанию
http://raspberrypimaker.com/adding-swap-to-the-raspberrypi/
Raspian uses a script dphys-swapfile to manage swap. The standard image includes this turned on by default. The configuration files is located at /etc/dphys-swapfile. Theonly parameter in the file is CONF_SWAPSIZE=100 which creates a 100MB swapfile in /var/swap.
да, но не в RAM же его
Хм, вроде как да — куда в RAM когда swap нужен когда RAM-а не хватает. Но и на SD ж не надо писать. Chicken and egg?
Но если еще подумать — допустим половину RAM-а мы отрезаем под RAM disk. Когда вторая половина (та, которая так сказать «RAM RAM») переолняется — пусть свопит в первую (ту, которая «RAM disk»), чего уж там. Так что таки swap в RAM, и «это норма» :D
Иначе прийдется совсем отключить swap. Вероятно наиболее логичный вариант, но надо нагуглить как.
Но если еще подумать — допустим половину RAM-а мы отрезаем под RAM disk. Когда вторая половина (та, которая так сказать «RAM RAM») переолняется — пусть свопит в первую (ту, которая «RAM disk»), чего уж там. Так что таки swap в RAM, и «это норма» :D
Иначе прийдется совсем отключить swap. Вероятно наиболее логичный вариант, но надо нагуглить как.
P.S. Прочел что вообще по-хорошему для таких дел используется zRam.
отключить swap очень просто: в /boot/cmdline.txt добавить
noswap и снести dphys-swapfile
Ещё вариант для безумцев — zRam (Тотже рамдиск, куда можно всунуть Swap, но при этом с сжатием-на-лету).
Хороший вариант, на старом телефоне с Android 4.0.3 и 512 МБ памяти только им и спасался.
да, компрессия — это единственная причина делать swap в ОЗУ; медленно и энергоёмко, но хоть как-то
Ни чё се медленно. Очень даже быстро, компрессия к слову используется в графических платах для увеличения пропускной способности. А там гигабиты в секунду, пуская и энтропия чрезвычайно невелика. У самого archlinux и 8 гигов RAM, так половину в zram отправил, компрессия хрома достигает 10%, что практически снимает вопрос о его прожорливости.
Deerenaros, если верить примитивным тестам на Doom и Quake 2 и сопоставлять их с официальным источником, то производительность загруженного по всем ядрам ARM Cortex A53 получится в 2-3 раза меньше, чем у старого десктопного Core i3 3220 (выпуска 2012 года). А если работает одно ядро, то Model 3 примерно в десять раз медленнее 4-летнего десктопа нижнего ценового ряда.
Когда я запустил слайд-шоу feh на фотках с паузой 7 секунд, сперва не мог понять, почему слайды меняются непредсказуемо каждые 10-12 секунд. Пока не глягул на загрузку ЦП: подгонка каждого фото профессиональной зеркалки под Full HD у BCM2837 как раз и занимает эти несколько секунд. Одно ядро пашет, три других курят, но это feh.
Вы тут упоминаете 8 гигов RAM, но у десктопа только на один ЦП подводится 50..100Вт мощности, а на видео может подводиться вообще сколько угодно. Компрессия в графических ускорителях? Видимо, даже 16-рядный PCI Express является бутылочным горлышком, в которое дешевле закачивать поток под давлением, ибо электрическая мощность в избытке. Про энтропию не буду комментировать.
У нас на весь одноплатный компьютер где-то 12Вт. Поэтому да, это будет медленнее, чем на десктопе, и когда у нас только 1Гб ОЗУ без возможности расширения, надо хорошо подумать, сколько на что отводить.
Но за 10-кратное сжатие расхода Chrome спасибо, кому-то пригодится.
Когда я запустил слайд-шоу feh на фотках с паузой 7 секунд, сперва не мог понять, почему слайды меняются непредсказуемо каждые 10-12 секунд. Пока не глягул на загрузку ЦП: подгонка каждого фото профессиональной зеркалки под Full HD у BCM2837 как раз и занимает эти несколько секунд. Одно ядро пашет, три других курят, но это feh.
Вы тут упоминаете 8 гигов RAM, но у десктопа только на один ЦП подводится 50..100Вт мощности, а на видео может подводиться вообще сколько угодно. Компрессия в графических ускорителях? Видимо, даже 16-рядный PCI Express является бутылочным горлышком, в которое дешевле закачивать поток под давлением, ибо электрическая мощность в избытке. Про энтропию не буду комментировать.
У нас на весь одноплатный компьютер где-то 12Вт. Поэтому да, это будет медленнее, чем на десктопе, и когда у нас только 1Гб ОЗУ без возможности расширения, надо хорошо подумать, сколько на что отводить.
Но за 10-кратное сжатие расхода Chrome спасибо, кому-то пригодится.
Про энтропию я имею в виду, что сжимать текстуры проще, тем более с потерями, чем любую информацию. И нет, не 16-разрядный PCI Express является горлышком. А высокая стоимость hispeed памяти неоправданно дорогой. Топовые карточки и без сжатия хорошо играются, а вот middle сегмент очень ограничен в пропускных возможностях.
У малинки есть классный видеоускоритель, который можно использовать для быстрой работы с изображениями. Ясное дело, feh такого не умеет.
Тут надо уточнить, что свапуется всё подряд, и отправить конкретно хром в свап не так то просто. Но в целом, хотя бы 40%-60% сжатие стабильно присутствует, что по сути как минимум удваивает количество RAM. А в случае интенсивного использования хрома, zram вероятнее утраивает, а порой даже удесятеряет. Меня порой удивляет, почему сами разработчики chromium не могут сами сжимать память различными методами, более эффективными.
У малинки есть классный видеоускоритель, который можно использовать для быстрой работы с изображениями. Ясное дело, feh такого не умеет.
Тут надо уточнить, что свапуется всё подряд, и отправить конкретно хром в свап не так то просто. Но в целом, хотя бы 40%-60% сжатие стабильно присутствует, что по сути как минимум удваивает количество RAM. А в случае интенсивного использования хрома, zram вероятнее утраивает, а порой даже удесятеряет. Меня порой удивляет, почему сами разработчики chromium не могут сами сжимать память различными методами, более эффективными.
Кстати, у малинки swapiness пи умолчанию стоит 60, т.e когда занято 40% RAM малинка начинает подумывать о сбросе данных в свап. Если поставить swapiness в 0, то он будет использоватся только когда по-другому никак.
( https://help.ubuntu.com/community/SwapFaq/#What_is_swappiness_and_how_do_I_change_it.3F )
( https://help.ubuntu.com/community/SwapFaq/#What_is_swappiness_and_how_do_I_change_it.3F )
спасибо за комментарий, но лично я считаю, что без SLC-памяти swap лучше отключить совсем, прописав
т.е. если без swap никак, надо сразу покупать HPE Flash Media Kit или аналог, в противном случае система может и полгода не протянуть
noswap в /boot/cmdline.txtт.е. если без swap никак, надо сразу покупать HPE Flash Media Kit или аналог, в противном случае система может и полгода не протянуть
Использую Domoticz, и несчастная SD-карта от SanDisk рушилась чуть ли ни каждую неделю.
Купил Transcend, перевел ее в read-only по этой статье и всё стало отлично.
Единственное, надо для некоторых служб создавать логи на ram-диске до их загрузки.
да, спасибо, но это чуть улучшенная версия варианта «без графики» в моих ссылках; тем не менее, я добавил Вашу ссылку, она полезна
напомню, у меня-то идея как раз с графикой заставить работать
по поводу же Domoticz — а не пробовали с OverlayFS? я ссылку на их wiki чуть выше уже дал
напомню, у меня-то идея как раз с графикой заставить работать
по поводу же Domoticz — а не пробовали с OverlayFS? я ссылку на их wiki чуть выше уже дал
Похожая картина с OpenHAB.
Использование под, собственно, OpenHAB плюс самописный скрипт для записи с двух видеокамер. Jpeg-и с камер писались в память (tmpfs), склеивались аппаратным кодеком и кидались на внешний HDD. Для системных логов был сделан самописный скрипт по типу ramLog, только под systemd.
Через примерно 5 месяцев начались глюки. Думал, умирает внешний SSD (из древних, что-то типа kingston/x25 40Gb). Оказалось, openHAB так «гадит» в свои логи, что всему raspbian-у и не снилось. Итог — «пафосный» sandisk на 32Гб от Юлмарта запилен до read-only
Сейчас: загрузка с sd, запуск ramLog-а, перемонтирование /var/{cache,lib/mosquitto} и бо́льшей части openHAB-а на внешний HDD и запуск xeoma с него же. Соответственно, /tmp, /run, /var/log — в tmpfs. Месяц отработало. За 20 дней 10Мб прочитано, 3.8Мб записано, если верить iostat
Использование под, собственно, OpenHAB плюс самописный скрипт для записи с двух видеокамер. Jpeg-и с камер писались в память (tmpfs), склеивались аппаратным кодеком и кидались на внешний HDD. Для системных логов был сделан самописный скрипт по типу ramLog, только под systemd.
Через примерно 5 месяцев начались глюки. Думал, умирает внешний SSD (из древних, что-то типа kingston/x25 40Gb). Оказалось, openHAB так «гадит» в свои логи, что всему raspbian-у и не снилось. Итог — «пафосный» sandisk на 32Гб от Юлмарта запилен до read-only
Сейчас: загрузка с sd, запуск ramLog-а, перемонтирование /var/{cache,lib/mosquitto} и бо́льшей части openHAB-а на внешний HDD и запуск xeoma с него же. Соответственно, /tmp, /run, /var/log — в tmpfs. Месяц отработало. За 20 дней 10Мб прочитано, 3.8Мб записано, если верить iostat
С августа 5 малин показывают браузер круглосуточно. Пока все живы. Из настроек только отключение в конфиге journald записи логов на диск и запуск браузера surf без кеширования. Когда одна из малин помрет, буду делать как у вас, unionfs. Спасибо за статью
У себя обошелся без дисплейного менеджера. Добавил файл /etc/systemd/system/getty@tty1.service.d/override.conf с таким содержанием:
Ну и мышь оставил, т.к. иногда нужно поуправлять работающей малиной напрямую. Программа unclutter скрывает указатель если его пару секунд не теребить
Все изменения в управляющих скриптах подготавливаю в виде deb-пакета на большой машине, затем массово заливаю и инсталирую по ssh. ssh-agent рулит
У себя обошелся без дисплейного менеджера. Добавил файл /etc/systemd/system/getty@tty1.service.d/override.conf с таким содержанием:
[Service]
ExecStart=
ExecStart=-/usr/bin/agetty --autologin user --noclear %I $TERM
Ну и мышь оставил, т.к. иногда нужно поуправлять работающей малиной напрямую. Программа unclutter скрывает указатель если его пару секунд не теребить
Все изменения в управляющих скриптах подготавливаю в виде deb-пакета на большой машине, затем массово заливаю и инсталирую по ssh. ssh-agent рулит
У меня RPi уже больше двух лет живет под Raspbian; сначала управлял роботом (пока не надоело), потом просто прозябает в виде веб-камеры через M-JPEG streamer (впрочем, еще использовал как сервер недолго, для эксперимента). Периодически апдейчу и апгрейжу (раз в квартал); все работает, как часы. Да, все с дешевой 4GB карточки (даже не помню, что туда засунул). Ничего в конфигах не отключал; X-ами не пользуюсь, все через ssh.
Что я делаю не так, зачем мне read-only file system, и когда оно таки «сдохнет»? ;)
Что я делаю не так, зачем мне read-only file system, и когда оно таки «сдохнет»? ;)
теоретически без swap и (особенно) без графики энтропия значительно ниже, но и модель карточки тоже интересно было бы узнать; у меня акцент на использовании графических приложений, именно они (в среднем) больший вклад в износ дают
Посмотрел специально: SONY, 16GB, 10 класса. Помню, были проблемы с более большей и скоростной карточкой (из-за какого-то бага в RPi или софте).
Да, весьма возможно, что при моем сценарии swap сильно не используется, потому и живет долго.
Да, весьма возможно, что при моем сценарии swap сильно не используется, потому и живет долго.
sens_boston, если Вас не затруднит, что скажут эти две команды (без root)?
uptime -p
cat /sys/block/mmcblk0/stat | awk '{printf "Uptime read: %.3fMiB written: %.3f MiB\n", $3*512/1048576, $7*512/1048576}'pi@raspberrypi ~ $ uptime -p
uptime: invalid option -- 'p'
Usage:
uptime [options]
Options:
-h, --help display this help and exit
-V, --version output version information and exit
For more details see uptime(1).
pi@raspberrypi ~ $ cat /sys/block/mmcblk0/stat | awk '{printf "Uptime read: %.3fMiB written: %.3f MiB\n", $3*512/1048576, $7*512/1048576}'
Uptime read: 40.826MiB written: 0.484 MiB
pi@raspberrypi ~ $
Вместо UnionFS можно использовать OverlayFS, он новее. Можно монтировать корень read-only, а поверх него монтировать OverlayFS в tmpfs, чтобы не приходилось монтировать отдельные директории.
И вообще, в Debian уже есть пакет для этого — live-boot и live-boot-initramfs-tools
И вообще, в Debian уже есть пакет для этого — live-boot и live-boot-initramfs-tools
А вот это интересно, спасибо.
Респект, ValdikSS! OverlayFS вошёл в ядро Linux уже после того «погибшего» немецкого поста про UnionFS, что не отменяет ценности OverlayFS сегодня. Но меня удивляет (и немного раздражает) молчание официальной команды Raspberry Pi по теме read-only root. К сожалению, комментарии читателей (не все!) и статистика опроса по среднему времени жизни Малиновых Прогов пока подтверждает мои опасения. Либо мы дружно смотрим не туда:)
Кстати, поисковики на запрос raspberry overlayfs выдают гораздо больше полезного, чем наraspberry read only root, в этом тоже есть профит от OverlayFS:)
Из того, что можно считать «пошаговой инструкцией», я нашёл только проект Domoticz и вот эту форумную ветку. Есть ещё что-то, достойное внимания?
Благодарю за ценный комментарий!
Кстати, поисковики на запрос raspberry overlayfs выдают гораздо больше полезного, чем на
Из того, что можно считать «пошаговой инструкцией», я нашёл только проект Domoticz и вот эту форумную ветку. Есть ещё что-то, достойное внимания?
Благодарю за ценный комментарий!
Полезно, надо бы и мне такое написать, а то уже забываю что да как у себя делал. И начал делать именно по этому же, что умирают microSD карточки.
У меня пирожки используются в качестве «мозгов» для информационных табло на базе HDMI мониторов/телевизоров. По сути там тольок Chrome выводящий страничку, которая по средствам JS обновляет внутри себя данные. Так вот эта, казалось бы тривиальная, задача убивает QUMO карточки на 8Gb (меньше в продаже у нас уже и не найти, да и эти стоили 400р.) в среднем за 2-3 месяца. Установка SNMP монитора (внешний сервер сбора статитика «Кактус») сразу открыла глаза на ситуацию. Raspberrian убивает карточку постоянной записью журнала и прочей ерунды типа логов и много чего ещё. При этом отключение журналирования не помогает, об этом есть целая ветка на linux.org.ru
С переходом на RO файловую систему всё стало шикарным! Не нарадуюсь. rsync'ом синхрю «изменения» которые делаю в конфигах, кэши броузера и темпы в память, логи на внешний сервер с небольшим буфером в память. Работает уже 6 мес, тфу тфу тфу со 100% аптаймом.
От текущеко решения отличатся разве, что тем, что я отказался от LightDM и поставил noDM, легче, проще, интуитивнее.
У меня пирожки используются в качестве «мозгов» для информационных табло на базе HDMI мониторов/телевизоров. По сути там тольок Chrome выводящий страничку, которая по средствам JS обновляет внутри себя данные. Так вот эта, казалось бы тривиальная, задача убивает QUMO карточки на 8Gb (меньше в продаже у нас уже и не найти, да и эти стоили 400р.) в среднем за 2-3 месяца. Установка SNMP монитора (внешний сервер сбора статитика «Кактус») сразу открыла глаза на ситуацию. Raspberrian убивает карточку постоянной записью журнала и прочей ерунды типа логов и много чего ещё. При этом отключение журналирования не помогает, об этом есть целая ветка на linux.org.ru
С переходом на RO файловую систему всё стало шикарным! Не нарадуюсь. rsync'ом синхрю «изменения» которые делаю в конфигах, кэши броузера и темпы в память, логи на внешний сервер с небольшим буфером в память. Работает уже 6 мес, тфу тфу тфу со 100% аптаймом.
От текущеко решения отличатся разве, что тем, что я отказался от LightDM и поставил noDM, легче, проще, интуитивнее.
6 лет назад то же самое делал на aufs2.
Я потому банану пи взял. У нее есть сата разьем. Я подключил жесткий диск и вот уже пол года все работает. До этого была расберри и проработала год без проблем. Я даже логгирование не отключал.
Read only системный диск — это же liveCD в чистом виде! Быть может, самым простым решением окажется просто эмуляция LiveCD с соответствующими дебиановскими либами?
Посмотрите как делает OpenWRT: системный образ в squashfs, настройки поверх через overlayfs.
Его можно собрать для малины, хотя я не пробовал. Не уверен, что squash нужен на SD, места то полно, но будет точно RO.
Раз уж подвернулась такая подходящая статья — расскажу свой «анекдот»
Была у меня малинка с установленной на ней RaspbianLite (без графики), и на ней маленькая программа, написанная на ноде, которая парсила некоторые сайты и отправляла результаты по сети в БД на удаленном сервере. Программа эта запускалась по крону каждый час.
Стояла себе моя малинка и работала себе, с почти полутора-годовым аптаймом.
В итоге в один прекрасный день я решил зайти на нее по ssh и проверить как у нее дела. Пробую зайти — нифига.
В итоге выяснилось что карта памяти полетела больше года назад (после e2fsck починилась), да еще и из разъема вылезла немного (он разболтан слегка был)
При этом служила мне верой и правдой все это время — просыпалась по крону, ходила в сеть и т.д.
В линуксе/юниксе я довольно-таки нуб, поэтому описать в техническом плане что именно там происходило не могу.
Но зато какой надежный девайс получился :)
Была у меня малинка с установленной на ней RaspbianLite (без графики), и на ней маленькая программа, написанная на ноде, которая парсила некоторые сайты и отправляла результаты по сети в БД на удаленном сервере. Программа эта запускалась по крону каждый час.
Стояла себе моя малинка и работала себе, с почти полутора-годовым аптаймом.
В итоге в один прекрасный день я решил зайти на нее по ssh и проверить как у нее дела. Пробую зайти — нифига.
В итоге выяснилось что карта памяти полетела больше года назад (после e2fsck починилась), да еще и из разъема вылезла немного (он разболтан слегка был)
При этом служила мне верой и правдой все это время — просыпалась по крону, ходила в сеть и т.д.
В линуксе/юниксе я довольно-таки нуб, поэтому описать в техническом плане что именно там происходило не могу.
Но зато какой надежный девайс получился :)
У меня похожая ситуация с FreeNAS послужила поводом к написанию статьи на хабре, система тоже жила себе на «сдохшей» флэшке около недели. Я прекрасно отдавал себе отчёт, что это до первой перезагрузки, и в случае с файл-сервером вмешался почти сразу, как только узнал, от греха подальше.
Однако обе мини-флэшки я не выбросил, а просто записал по-новой. Одна до сих пор в автомагнитоле прекрасно служит MP3-архивом, воспроизводя мне эфиры давно закрытых, но до боли любимых радиостанций. Вторая трудится (ха-ха) загрузчиком тестового FreeNAS, на котором я отрабатываю проброс аппаратных USB-ключей жёлтой программы через jail и virtualbox прямо в установленный тут же Windows. И хорошо работает, но я так скажу: слава богу, что это хобби:)
Однако обе мини-флэшки я не выбросил, а просто записал по-новой. Одна до сих пор в автомагнитоле прекрасно служит MP3-архивом, воспроизводя мне эфиры давно закрытых, но до боли любимых радиостанций. Вторая трудится (ха-ха) загрузчиком тестового FreeNAS, на котором я отрабатываю проброс аппаратных USB-ключей жёлтой программы через jail и virtualbox прямо в установленный тут же Windows. И хорошо работает, но я так скажу: слава богу, что это хобби:)
Наверное, еще можно адаптироватъ старый способ создания Live CD: http://www.linuxfromscratch.org/hints/downloads/files/OLD/bootcd-2.6-udev-nptl.txt
Использую Flash Media Kits от HPE для загрузки ESXi и OpenIndiana.
Эти SD и microSD рассчитаны на большее количество циклов перезаписи (до 100 000) чем обычные консьюмерские флешки.
Стоимость — в несколько раз дороже, но для долгосрочного (обычно — 2-4 года) использования в продакшене оправдана.
Эти SD и microSD рассчитаны на большее количество циклов перезаписи (до 100 000) чем обычные консьюмерские флешки.
Стоимость — в несколько раз дороже, но для долгосрочного (обычно — 2-4 года) использования в продакшене оправдана.
вот, в том числе ради таких комментариев я и пишу свои публикации:)
теперь я знаю, под каким брэндом можно найти промышленную SLC-память в формате microSD, огромное спасибо!
теперь я знаю, под каким брэндом можно найти промышленную SLC-память в формате microSD, огромное спасибо!
зашел по Вашей ссылке ниже: разница в цене — 10+ раз для варианта 32 ГБ.
Если железка не будет расположена в каком-то труднообслуживаемом месте,
то имхо дешевле по регламенту менять дешевые карты чаще, чем надеяться на обещанную надежность такого дорогого варианта.
Причем память б0льшего размера позволит размазывать износ дольше и дальше — еще и поэтому меньший размер менее выгоден, а не только сами по себе мелкие карточки выходят дороже в пересчете на единицу памяти.
Если железка не будет расположена в каком-то труднообслуживаемом месте,
то имхо дешевле по регламенту менять дешевые карты чаще, чем надеяться на обещанную надежность такого дорогого варианта.
Причем память б0льшего размера позволит размазывать износ дольше и дальше — еще и поэтому меньший размер менее выгоден, а не только сами по себе мелкие карточки выходят дороже в пересчете на единицу памяти.
износ флэша даже в режиме ридонли — это потемки, например http://habrahabr.ru/post/214803/
Также интересуюсь командой TRIM для не-SSD.
У некоторых eMMC уже стал появляться SMART http://4pda.ru/forum/index.php?showtopic=170318&view=findpost&p=42683000
Заранее благодарю за любую информацию по этим темам.
Также интересуюсь командой TRIM для не-SSD.
У некоторых eMMC уже стал появляться SMART http://4pda.ru/forum/index.php?showtopic=170318&view=findpost&p=42683000
Заранее благодарю за любую информацию по этим темам.
Здравствуйте, дорогой читатель! Я очень хорошо знаю автора той статьи на хабре (это я и есть:)
На наше с Вами счастье буквально за минуту до Вашего комментария сюда зашёл пользователь gattopazzo83 и рассказал про SLC-память в формате microSD, которая является промышленной по своему назначению. А это означает, что подобных эффектов износа через read-only там быть не должно просто по определению. Конечно, космический корабль на этом не запустишь (радиация, вибрация, и всё такое), но для гражданских проектов вполне.
На наше с Вами счастье буквально за минуту до Вашего комментария сюда зашёл пользователь gattopazzo83 и рассказал про SLC-память в формате microSD, которая является промышленной по своему назначению. А это означает, что подобных эффектов износа через read-only там быть не должно просто по определению. Конечно, космический корабль на этом не запустишь (радиация, вибрация, и всё такое), но для гражданских проектов вполне.
спасибо за пропуск АКА модерацию.
Если обе статьи за Вашим авторством, то странно, что никто больше не заметил странностей с таким режимом ридонли, который все равно приводит именно к быстрому износу флэша.
имхо SLC-память в формате microSD — не панацея до тех пор, пока не будет неких дополнительных гарантий в ее надежности, кроме ломовой цены и пафосного ценника.
Например, для андроида есть много бесплатных программ, которые показывают много «скрытой» инфы про внутреннюю и внешнюю память — интересно было бы применить этот визуализатор к тем дорогим картам.
И повторюсь насчет TRIM:
не попалось мне никаких намеков на то, что не любой контроллер не у всякой флеш поддерживает команду fstrim, которая появилась у Андроида 4.3
хотя про «взрослые» SSD море инфы о том, что многие ранние SSD не поддерживали эту фичу и требовали полного стирания для восстановления былых скоростей.
Буду благодарен за любые ссылки для чтения по всем этим смежным темам.
Если обе статьи за Вашим авторством, то странно, что никто больше не заметил странностей с таким режимом ридонли, который все равно приводит именно к быстрому износу флэша.
имхо SLC-память в формате microSD — не панацея до тех пор, пока не будет неких дополнительных гарантий в ее надежности, кроме ломовой цены и пафосного ценника.
Например, для андроида есть много бесплатных программ, которые показывают много «скрытой» инфы про внутреннюю и внешнюю память — интересно было бы применить этот визуализатор к тем дорогим картам.
И повторюсь насчет TRIM:
не попалось мне никаких намеков на то, что не любой контроллер не у всякой флеш поддерживает команду fstrim, которая появилась у Андроида 4.3
хотя про «взрослые» SSD море инфы о том, что многие ранние SSD не поддерживали эту фичу и требовали полного стирания для восстановления былых скоростей.
Буду благодарен за любые ссылки для чтения по всем этим смежным темам.
* пафосного лебла
к Вашему комментарию выше про x10+ ценник да, всё в конечном итоге определяет экономика процесса обслуживания, дома дешевле перезалить систему, в бизнесе дешевле купить SLC-память
По моей теории, порча данных при чтении в результате read disturb возможна в результате слабого алгоритма расчёта контрольных сумм или багов в микроконтроллере, при этом флэшка остаётся работоспособной, т.е. перезапись восстанавливает «повреждённый» участок. Это вроде бы не противоречит тезисам доклада Jim Cooke в 2007г, но у меня нет ни оборудования, ни времени, ни навыков, чтобы доказать это на практическом примере.
Когда я смотрю на характеристики памяти и вижу 100,000 циклов записи, второе место, куда я смотрю — это информация о длине контрольной суммы. И если она декларируется, это о многом говорит. А принятие решения о правдивости всей этой информации проще при наличии брэнда, которому репутационные издержки утопят выгоду от вранья. Поэтому если новый HP начал продавать такие флэшки, то я охрененно рад, если честно:) И да, износ 32Гб при прочих равных должен идти в четыре раза медленнее, чем 8Гб.
Вижу, Вам TRIM на SD просто не даёт покоя:) Даже если команды Линукса что-то там отрабатывают и показывают на SD-карточке, это не SSD, тут наличие реального физического процесса вызывает гораздо больше сомнений, чем обещанная надёжность изделий от HPE. Искали, кстати, «fstrim sd card»? Вот, например: https://www.raspberrypi.org/forums/viewtopic.php?t=19554. Народ сходится на том, что отправка на запись полного нулей блока должна иметь только эффект ERASE, т.е. без записи самих нулей. Микроконтроллер понимает, что это затёртый блок, и в следующий раз при чтении быстро «напечатает» порцию нулей и выдаст хосту. Я в это готов поверить, тем более, что логика гипервизоров аналогична. Например, VMware с thin-provisioned дисками работает именно так. Но, поскольку это прошивка микроконтроллера, что происходит на самом деле, зависит от честности вендора, т.е. приходим к тому же выводу, что и в моей публикации 2014г.
странно, что никто больше не заметил странностей с таким режимом ридонли, который все равно приводит именно к быстрому износу флэша
По моей теории, порча данных при чтении в результате read disturb возможна в результате слабого алгоритма расчёта контрольных сумм или багов в микроконтроллере, при этом флэшка остаётся работоспособной, т.е. перезапись восстанавливает «повреждённый» участок. Это вроде бы не противоречит тезисам доклада Jim Cooke в 2007г, но у меня нет ни оборудования, ни времени, ни навыков, чтобы доказать это на практическом примере.
Когда я смотрю на характеристики памяти и вижу 100,000 циклов записи, второе место, куда я смотрю — это информация о длине контрольной суммы. И если она декларируется, это о многом говорит. А принятие решения о правдивости всей этой информации проще при наличии брэнда, которому репутационные издержки утопят выгоду от вранья. Поэтому если новый HP начал продавать такие флэшки, то я охрененно рад, если честно:) И да, износ 32Гб при прочих равных должен идти в четыре раза медленнее, чем 8Гб.
Вижу, Вам TRIM на SD просто не даёт покоя:) Даже если команды Линукса что-то там отрабатывают и показывают на SD-карточке, это не SSD, тут наличие реального физического процесса вызывает гораздо больше сомнений, чем обещанная надёжность изделий от HPE. Искали, кстати, «fstrim sd card»? Вот, например: https://www.raspberrypi.org/forums/viewtopic.php?t=19554. Народ сходится на том, что отправка на запись полного нулей блока должна иметь только эффект ERASE, т.е. без записи самих нулей. Микроконтроллер понимает, что это затёртый блок, и в следующий раз при чтении быстро «напечатает» порцию нулей и выдаст хосту. Я в это готов поверить, тем более, что логика гипервизоров аналогична. Например, VMware с thin-provisioned дисками работает именно так. Но, поскольку это прошивка микроконтроллера, что происходит на самом деле, зависит от честности вендора, т.е. приходим к тому же выводу, что и в моей публикации 2014г.
So even if the SDHC cards don't support the trim command the erase block command of the SDHC card might actually do quite the same, since it's too fast for a real physical erase procedure but it still results in a block being reread as zero.
Note that this might well be device and or vendor specific behaviour, its what i saw while working with sandisc SDHC cards on a dataloggger project with a microcontroller using SPI protocoll for communication.
> порча данных при чтении в результате read disturb возможна в результате…
а я не понимаю самого обмана:
либо в режиме ридонли все равно что-то пишется — и это Ваша же гипотеза про ехт4,
либо описание «механизма износа» флэша в паблике не раскрывает всех тонкостей этого самого износа.
Например, про литиевые батареи давно проталкивают мысль, что они изнашиваются даже лежа на складе при правильной температуре — просто от времени хранения. Но литий — это химия, а флэш — пока еще физика, вроде бы: вот это мне и непонятно.
TRIM на SD не даёт мне покоя по простой причине: это предельно наглядный метод проверки продвинутости или даже вообще наличия мозгов у контроллера.
Все же, для дешевых и левых флешей я бы предположил просто полное отсутствие алгоритмов размазывания износа: такой вариант легко объяснил бы обсуждаемый 2-месячный износ без привлечения излишних сущностей вроде SLC/MLC/TLC.
имхо ламера: логику гипервизоров неверно сравнивать с производством предельно дешевых флэш карт\свистков.
а «честность вендоров» давно подмочена подменой «1024 мегабайт» на «1000 мегабайт». Я тут выше уже приводил ссылку, что у некоторых еММС появился SMART — вот только в это можно будет как-то поверить…
а я не понимаю самого обмана:
либо в режиме ридонли все равно что-то пишется — и это Ваша же гипотеза про ехт4,
либо описание «механизма износа» флэша в паблике не раскрывает всех тонкостей этого самого износа.
Например, про литиевые батареи давно проталкивают мысль, что они изнашиваются даже лежа на складе при правильной температуре — просто от времени хранения. Но литий — это химия, а флэш — пока еще физика, вроде бы: вот это мне и непонятно.
TRIM на SD не даёт мне покоя по простой причине: это предельно наглядный метод проверки продвинутости или даже вообще наличия мозгов у контроллера.
Все же, для дешевых и левых флешей я бы предположил просто полное отсутствие алгоритмов размазывания износа: такой вариант легко объяснил бы обсуждаемый 2-месячный износ без привлечения излишних сущностей вроде SLC/MLC/TLC.
имхо ламера: логику гипервизоров неверно сравнивать с производством предельно дешевых флэш карт\свистков.
а «честность вендоров» давно подмочена подменой «1024 мегабайт» на «1000 мегабайт». Я тут выше уже приводил ссылку, что у некоторых еММС появился SMART — вот только в это можно будет как-то поверить…
* имхо ламера: логику гипервизоров неверно сравнивать с производством предельно дешевых флэш карт\свистков. Т.е., очевидно, что контроллер без размазывания износа выйдет драматически дешевле и проще, чем интеллектуальный. А ведь на таких масштабах производства и при таких ценах экономия даже долей цента оборачивается большими суммами.
либо в режиме ридонли все равно что-то пишется — и это Ваша же гипотеза про ехт4,NAND read disturb «на пальцах» — это постепенная порча данных в каком-то месте, вызванное чтением из «соседнего» участка, исправляется перезаписью, и следить за этим достаточно просто, чтобы обычный микроконтроллер справился (только прошивка нужна без багов, а это и есть интеллектуальная собственность корпораций). Для меня сочетание SLC, длинной контрольной суммы и хорошего брэнда как раз означает, что в прошивку залит достаточно продвинутый софт, чтобы флэшка даже с записью жила долго, а в режиме read-only — очень долго, без всяких намёков на read disturb…
либо описание «механизма износа» флэша в паблике не раскрывает всех тонкостей этого самого износа
Мы же с Вами ищем одно и то же, верно? Вы также пытаетесь оценивать «продвинутость» софта микроконтроллера, но только по критерию наличия TRIM, я правильно понял? В примитивном (относительно SSD) интерфейсе SD-карточек нет такой функции, так википедия утверждает:
The MultiMediaCard and SD ERASE (CMD38) command provides similar functionality to the ATA TRIM command, although it requires that erased blocks be overwritten with either zeroes or ones. eMMC 4.5 further defines a «discard» sub-operation that more closely matches ATA TRIM in that the contents of discarded blocks can be considered indeterminate (i.e., «don't care»).
Так что тут вопрос и к драйверам (ядру) Linux, и к железу, и к userland командам…
Как бы там ни было, причина, побудившая меня написать эту статью — наплевательское отношение к культуре использования ограниченного ресурса SD-карточек со стороны «готовых» образов систем для RPi. Проблему явно надо с двух концов решать.
У Вас есть МалинПрог под рукой? Можете поставить hdparm и запустить одну команду?
hdparm -I /dev/mmcblk0Я просто не хочу до нового года вообще трогать торговое оборудование…
Про гипервизоры: я имел в виду, что «раздутый» шлаком (стёртыми файлами) Thin Provisioned Disk VMware «сдувается» обратно при помощи записанных поверх стёртых файлов «нулей», блоки которых гипервизор считает пустыми. См. ссылку про vmkfstools --punchzero. У некоторых SD-карточек «нулевые» блоки означают для микроконтроллера то же самое, что «нулевые» блоки для команды vmkfstools. Просто неслучайная аналогия, для Thin Provisioned Disk команда TRIM была бы тоже полезна.
википедии нельзя верить в областях, где прогресс быстр, а инфа все еще не устоялась: даже про HDD с их черепичной записью и гелием нельзя верить вики, потому что такой опыт еще не наработан, а грабли не хожены.
Т.е., признание отсутствия TRIM лишь еще сильнее намекает и на полное отсутствие алгоритма размазывания износа, хотя для SD про последнее никто не пишет прямо ни «за», ни «против».
наплевательское отношение к культуре использования ограниченного ресурса SD-карточек со стороны «готовых» образов систем для RPi — имхо явное следствие дешевизны карт памяти и тупости основного контингента, которые приучены к этому фреймворками и прочими улучшателями и упрощателями.
вопросы и к драйверам (ядру) Linux, и к железу, и к userland командам хотя бы имеют ответы, а вот про кишки карт памяти неизвестно ничего, например
https://habrahabr.ru/post/273425/
> во встроенном в eMMC уровне FTL тоже реализованы алгоритмы выравнивания износа, но это «черный ящик».
> у некоторых SD-карточек «нулевые» блоки означают для микроконтроллера
да, кроме неафишируемого использования SLC, также возможно, что некоторые карты не рекламируют но имеют и продвинутые контроллеры
у меня нет МалинПрог под рукой — я ламер и просто собираю инфу по некоторым волнующим меня темам.
Т.е., признание отсутствия TRIM лишь еще сильнее намекает и на полное отсутствие алгоритма размазывания износа, хотя для SD про последнее никто не пишет прямо ни «за», ни «против».
наплевательское отношение к культуре использования ограниченного ресурса SD-карточек со стороны «готовых» образов систем для RPi — имхо явное следствие дешевизны карт памяти и тупости основного контингента, которые приучены к этому фреймворками и прочими улучшателями и упрощателями.
вопросы и к драйверам (ядру) Linux, и к железу, и к userland командам хотя бы имеют ответы, а вот про кишки карт памяти неизвестно ничего, например
https://habrahabr.ru/post/273425/
> во встроенном в eMMC уровне FTL тоже реализованы алгоритмы выравнивания износа, но это «черный ящик».
> у некоторых SD-карточек «нулевые» блоки означают для микроконтроллера
да, кроме неафишируемого использования SLC, также возможно, что некоторые карты не рекламируют но имеют и продвинутые контроллеры
у меня нет МалинПрог под рукой — я ламер и просто собираю инфу по некоторым волнующим меня темам.
RPi B+, Raspbian jessie: hdparm не хочет показывать информацию об SD-карте:
# hdparm -I /dev/mmcblk0
/dev/mmcblk0:
HDIO_DRIVE_CMD(identify) failed: Invalid argument
всё верно, SD-карточка не диск, я был неправ, вот команда:
см. также спойлер в публикации
udevadm info -a -n /dev/mmcblk0см. также спойлер в публикации
Raspi B+, Transcend 8GB class 10
# udevadm info -a -n /dev/mmcblk0
Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/devices/platform/soc/20202000.sdhost/mmc_host/mmc0/mmc0:aaaa/block/mmcblk0':
KERNEL=="mmcblk0"
SUBSYSTEM=="block"
DRIVER==""
ATTR{ro}=="0"
ATTR{size}=="15523840"
ATTR{stat}==" 4491 1914 202850 16300 1386 1625 24289 26390 0 13340 42620"
ATTR{range}=="32"
ATTR{discard_alignment}=="0"
ATTR{force_ro}=="0"
ATTR{ext_range}=="32"
ATTR{alignment_offset}=="0"
ATTR{inflight}==" 0 0"
ATTR{removable}=="0"
ATTR{capability}=="10"
looking at parent device '/devices/platform/soc/20202000.sdhost/mmc_host/mmc0/mmc0:aaaa':
KERNELS=="mmc0:aaaa"
SUBSYSTEMS=="mmc"
DRIVERS=="mmcblk"
ATTRS{cid}=="035344534c303847803da92ee4010481"
ATTRS{csd}=="400e00325b5900003b377f800a4040af"
ATTRS{scr}=="0235800100000000"
ATTRS{date}=="04/2016"
ATTRS{name}=="SL08G"
ATTRS{type}=="SD"
ATTRS{preferred_erase_size}=="4194304"
ATTRS{fwrev}=="0x0"
ATTRS{hwrev}=="0x8"
ATTRS{oemid}=="0x5344"
ATTRS{manfid}=="0x000003"
ATTRS{serial}=="0x3da92ee4"
ATTRS{erase_size}=="512"
looking at parent device '/devices/platform/soc/20202000.sdhost/mmc_host/mmc0':
KERNELS=="mmc0"
SUBSYSTEMS=="mmc_host"
DRIVERS==""
looking at parent device '/devices/platform/soc/20202000.sdhost':
KERNELS=="20202000.sdhost"
SUBSYSTEMS=="platform"
DRIVERS=="sdhost-bcm2835"
ATTRS{driver_override}=="(null)"
looking at parent device '/devices/platform/soc':
KERNELS=="soc"
SUBSYSTEMS=="platform"
DRIVERS==""
ATTRS{driver_override}=="(null)"
looking at parent device '/devices/platform':
KERNELS=="platform"
SUBSYSTEMS==""
DRIVERS==""
Olimex A13, SanDisk Ultra 8GB class 10
# udevadm info -a -n /dev/mmcblk0
Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/devices/platform/sunxi-mmc.0/mmc_host/mmc0/mmc0:aaaa/block/mmcblk0':
KERNEL=="mmcblk0"
SUBSYSTEM=="block"
DRIVER==""
ATTR{ro}=="0"
ATTR{size}=="15523840"
ATTR{stat}==" 5839 3033 327488 15840 1378 801 17850 7150 0 13780 22900"
ATTR{range}=="8"
ATTR{discard_alignment}=="0"
ATTR{force_ro}=="0"
ATTR{ext_range}=="256"
ATTR{alignment_offset}=="0"
ATTR{inflight}==" 0 0"
ATTR{removable}=="0"
ATTR{capability}=="50"
looking at parent device '/devices/platform/sunxi-mmc.0/mmc_host/mmc0/mmc0:aaaa':
KERNELS=="mmc0:aaaa"
SUBSYSTEMS=="mmc"
DRIVERS=="mmcblk"
ATTRS{cid}=="035344534c30384780657324d401078b"
ATTRS{csd}=="400e00325b5900003b377f800a4040af"
ATTRS{scr}=="0235800100000000"
ATTRS{date}=="07/2016"
ATTRS{name}=="SL08G"
ATTRS{type}=="SD"
ATTRS{preferred_erase_size}=="4194304"
ATTRS{fwrev}=="0x0"
ATTRS{hwrev}=="0x8"
ATTRS{oemid}=="0x5344"
ATTRS{manfid}=="0x000003"
ATTRS{serial}=="0x657324d4"
ATTRS{erase_size}=="512"
looking at parent device '/devices/platform/sunxi-mmc.0/mmc_host/mmc0':
KERNELS=="mmc0"
SUBSYSTEMS=="mmc_host"
DRIVERS==""
looking at parent device '/devices/platform/sunxi-mmc.0':
KERNELS=="sunxi-mmc.0"
SUBSYSTEMS=="platform"
DRIVERS=="sunxi-mmc"
looking at parent device '/devices/platform':
KERNELS=="platform"
SUBSYSTEMS==""
DRIVERS==""
Raspi B+, Transcend 8GB class 10
если верить CID, память производена SanDisk в апреле 2016
с момента запуска системы прочитано 202850 блоков, записано 24289 (соотношение 8:1)
Olimex A13, SanDisk Ultra 8GB class 10
если верить CID, память произведена SanDisk в июле 2016
с момента запуска системы прочитано 327488 блоков, записано 17850 (соотношение 18:1)
обе файловых системы явно работают в режиме read-write (у меня на «read-only» соотношение 3000:1)
Можно выполнить uptime -p и разделить записанные блоки на часы (точнее, сутки), получите средесуточный износ флэшки. Умножаете на количество дней работы устройства. Предел у MLC памяти 3000..5000 циклов записи, т.е. примерно после 32Тб записанных данных флэшка должна сдохнуть. Блок 512 байт, с момента запуска системы записали 11Мб на первую флэшку и 8Мб на вторую.
Вот если бы скомпилировать утилиты для IOCTL-вызовов, из SanDisk можно было бы вытащить аналог S.M.A.R.T., см. ссылку пользователя doga. Мой МалинПрог трудится в production, я второй пока не завёл:) Вы работаете с исходным кодом? Умеете пакеты под Debian собирать?
если верить CID, память производена SanDisk в апреле 2016
с момента запуска системы прочитано 202850 блоков, записано 24289 (соотношение 8:1)
Olimex A13, SanDisk Ultra 8GB class 10
если верить CID, память произведена SanDisk в июле 2016
с момента запуска системы прочитано 327488 блоков, записано 17850 (соотношение 18:1)
обе файловых системы явно работают в режиме read-write (у меня на «read-only» соотношение 3000:1)
Можно выполнить uptime -p и разделить записанные блоки на часы (точнее, сутки), получите средесуточный износ флэшки. Умножаете на количество дней работы устройства. Предел у MLC памяти 3000..5000 циклов записи, т.е. примерно после 32Тб записанных данных флэшка должна сдохнуть. Блок 512 байт, с момента запуска системы записали 11Мб на первую флэшку и 8Мб на вторую.
Вот если бы скомпилировать утилиты для IOCTL-вызовов, из SanDisk можно было бы вытащить аналог S.M.A.R.T., см. ссылку пользователя doga. Мой МалинПрог трудится в production, я второй пока не завёл:) Вы работаете с исходным кодом? Умеете пакеты под Debian собирать?
а где берёте расшифровку cid? что-то находятся противоречивые данные, в самом mmc-utils ерунда какая-то (например MID 0x1b определяется как transcend, хотя это должен быть самсунг)
судя по тем картам, что на руках, вроде бы вот тут адекватные значения для MID:
https://www.cameramemoryspeed.com/sd-memory-card-faq/reading-sd-card-cid-serial-psn-internal-numbers/
но список неполный.
Вот если бы скомпилировать утилиты для IOCTL-вызовов
вы про mmc-utils? они собираются легко, однако
root@raspberrypi:/usr/src/mmc-utils# ./mmc extcsd read /dev/mmcblk0
ioctl: Connection timed out
Could not read EXT_CSD from /dev/mmcblk0а где берёте расшифровку cid?не помню, уйма лет прошла:) сейчас вот просто нагуглил «microsd decode cid», например: goughlui.com/static/multicid.htm
ioctl: Connection timed outесли охота заниматься, можно пройтись по исходному коду драйвера; может, его просто недописали в этом месте за ненадобностью. Полноценные SSD дешевеют, там всё должно быть. А microSD — это так, для игрушек:)
не помню, уйма лет прошла:) сейчас вот просто нагуглил «microsd decode cid», например: goughlui.com/static/multicid.htm
этот и я находил, но он тоже "не фонтан"
Полноценные SSD
ну малинка обычно таки используется с microsd
ну малинка обычно таки используется с microsdэто да, но я не воспринимаю microSD как место для регулярной записи и хранения изменяемой информации; это условный ROM с прошивкой, а регулярную запись лучше делать либо по сети, либо на отдельный носитель (хоть на тот же SSD по USB). Да и с безопасностью на read-only файловой системе получше, особенно с учётом культуры обновлений (точнее, их полным отсутвием:)
-del-
согласен, тоже пришёл к хранению данных вне microsd:
https://habr.com/ru/post/479044/
… а вместо SSD можно использовать промышленные USB-флэшки, например, Transcend SuperMLC (изделие TS8GJF740K или другое) — компактный форм-фактор и крепкий сон, потому что даже при отказе записи сам одноплатник будет жить и отзываться по сети
А почему не SquashFS?
благодарю за комментарий, ответил Вам и другим читателям в публикации, см. UPD: SquashFS
Благодарю за ответ. Согласен, невозможность изменить внутренности SquashFS может затруднить устранение ошибок на этапе эксплуатации.
Но можно взглянуть на это и с другой стороны: неизменимость образа SquashFS может быть и достоинством — никакой вирус или троян не сможет закрепиться в системе, после перезагрузки система гарантированно вернётся в исходное состояние. Обновления же можно распространять в виде готового squashfs-образа. В тех же роутерах, например, новую прошивку тоже в виде целого образа распространяют. Не берусь утверждать, возможно ли подменить образ из загруженной с него системы, но полагаю, что даже если и нет, можно что-нибудь придумать.
Но можно взглянуть на это и с другой стороны: неизменимость образа SquashFS может быть и достоинством — никакой вирус или троян не сможет закрепиться в системе, после перезагрузки система гарантированно вернётся в исходное состояние. Обновления же можно распространять в виде готового squashfs-образа. В тех же роутерах, например, новую прошивку тоже в виде целого образа распространяют. Не берусь утверждать, возможно ли подменить образ из загруженной с него системы, но полагаю, что даже если и нет, можно что-нибудь придумать.
Занимаемся счетчиками пассажиров на транспорте, используются как раз малинки (1,2.3). Есть с аптаймом по полгода, есть такие, которые перезагружаются каждые несколько минут (в таком режиме сдох роутер, малина с системой жива). Считают пассажиров, объявляют остановки, выполняют функции бортового компьютера. Вся ОС грузится в память, карточка не смонтирована совсем, потому что даже при монтировании в рид-онли система жила не больше месяца
Приветствую, очень приятно видеть здесь представителей отраслей! По поводу износа через чтение я как-то писал статью на хабре, смысл которой сводится к простой рекомендации: с учётом «физики» NAND-памяти не стоит использовать бытовые изделия для промышленных задач, потому что сэкономить можно и на софте для управляющего микроконтроллера флэшки. И mount read-only не означает, что драйвер файловой системы не попытается отметить дату и время последнего успешного монтажа. Отучить его от этой привычки можно, пожалуй, только аппаратным переключателем записи, но вот где на microSD он встречается?
Тем не менее, благодаря пользователю gattopazzo83 я теперь знаю про флэшки Flash Media Kit пр-ва известной фирмы Харлампий-Панкрат (Эдуардович), и для Ваших задач определённо их рекомендую. Стоят дорого, но зато это SLC microSD.
Тем не менее, благодаря пользователю gattopazzo83 я теперь знаю про флэшки Flash Media Kit пр-ва известной фирмы Харлампий-Панкрат (Эдуардович), и для Ваших задач определённо их рекомендую. Стоят дорого, но зато это SLC microSD.
«аппаратный переключатель записи» расположен в слоте, а на карте если и есть, то только механический движок, не связанный ни с чем более
К слову эти «бытовые изделия для промышленных задач» используются несколько лет компанией FlightAware http://flightaware.com/adsb/flightfeeder/
Софт тут — https://github.com/flightaware
Софт тут — https://github.com/flightaware
И mount read-only не означает, что драйвер файловой системы не попытается отметить дату и время последнего успешного монтажа.
вы неправы
root@raspberrypi:~# umount /dev/mmcblk0p1
root@raspberrypi:~# md5sum /dev/mmcblk0p1
3663aaaf7a30cec1da95b98024750c33 /dev/mmcblk0p1
root@raspberrypi:~# mount -o ro /dev/mmcblk0p1
root@raspberrypi:~# md5sum /boot/config.txt
321fff4ec7f6ee1b915c4b846eb38e91 /boot/config.txt
root@raspberrypi:~# umount /dev/mmcblk0p1
root@raspberrypi:~# md5sum /dev/mmcblk0p1
3663aaaf7a30cec1da95b98024750c33 /dev/mmcblk0p1
root@raspberrypi:~# mount /dev/mmcblk0p1
root@raspberrypi:~# md5sum /boot/config.txt
321fff4ec7f6ee1b915c4b846eb38e91 /boot/config.txt
root@raspberrypi:~# umount /dev/mmcblk0p1
root@raspberrypi:~# md5sum /dev/mmcblk0p1
878cd7371915f41a264c0286779a652c /dev/mmcblk0p1(смонтировали с -o ro, прочитали файл, размонтировали — ни одного байта не измелось, то же самое без -o ro — хэш поменялся)
карточка не смонтирована совсем, потому что даже при монтировании в рид-онли система жила не больше месяца
интересно, в чём разница? так и так при начальной загрузке идёт чтение с флешки, а при монтировании в read-only записи быть не должно.
и интересно, какая у вас статистика спустя три года
Не знаю, почему есть разница, но она есть. Был случай, когда неправильно подключили электропитание к системе, и Raspberry включалась каждые 5 минут на 2-3 минуты, после чего отключалось питание. Через две недели вышел из строя роутер, который раздавал интернет на эти системы в транспорте («побилась» прошивка), а Raspberry выжили и работали (замена карточек не производилась). Сейчас по году и больше работают, зависит от модели microSD.
Так-то для read-only можно было собрать ту же бубунту в squashfs
Блин. У меня openELEC с KODI пару месяцев работает. Тоже сдохнет?
может, вот так прямо и не сдохнет, особенно если Вы установили это на дорогую флэшку типа HPE Flash Media Kit
но зато какая интрига! :))
но зато какая интрига! :))
Transcend на 16 ГБ. Из приличных вроде. Буду смотреть) в openELEC все гвоздями изрядно прибито. У них даже apt-get закрыт. Образ не трогал)
Уважаемый Meklon, можете отдать две команды из-под root и показать нам результат?
Надо, чтобы система была на ходу несколько дней, с Вашей штатной нагрузкой, без резких бросков.
Можете ответ в личку отправить, если сюда — то обязательно в спойлер.
Я попробую оценить суточный износ и остаток ресурса, на большее пока не готов:)
Надо, чтобы система была на ходу несколько дней, с Вашей штатной нагрузкой, без резких бросков.
udevadm info -a -n /dev/mmcblk0
uptime -pМожете ответ в личку отправить, если сюда — то обязательно в спойлер.
Я попробую оценить суточный износ и остаток ресурса, на большее пока не готов:)
Брошу, ок) я сам линуксоид, просто лень ковырять исходный образ было)
udevadm info -a -n /dev/mmcblk0
Meklon-Kitchen:~ # udevadm info -a -n /dev/mmcblk0
Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/devices/platform/soc/3f202000.sdhost/mmc_host/mmc0/mmc0:59b4/block/mmcblk0':
KERNEL=="mmcblk0"
SUBSYSTEM=="block"
DRIVER==""
ATTR{ro}=="0"
ATTR{size}=="31586304"
ATTR{stat}==" 2250 740 147420 8920 8963 7499 134874 273290 0 49473 282233"
ATTR{range}=="32"
ATTR{discard_alignment}=="0"
ATTR{force_ro}=="0"
ATTR{ext_range}=="32"
ATTR{alignment_offset}=="0"
ATTR{inflight}==" 0 0"
ATTR{removable}=="0"
ATTR{capability}=="10"
looking at parent device '/devices/platform/soc/3f202000.sdhost/mmc_host/mmc0/mmc0:59b4':
KERNELS=="mmc0:59b4"
SUBSYSTEMS=="mmc"
DRIVERS=="mmcblk"
ATTRS{cid}=="744a605553445531203ba13fbd00f573"
ATTRS{csd}=="400e00325b590000787d7f800a400005"
ATTRS{scr}=="0235800300000000"
ATTRS{date}=="05/2015"
ATTRS{name}=="USDU1"
ATTRS{type}=="SD"
ATTRS{preferred_erase_size}=="4194304"
ATTRS{fwrev}=="0x0"
ATTRS{hwrev}=="0x2"
ATTRS{oemid}=="0x4a60"
ATTRS{manfid}=="0x000074"
ATTRS{serial}=="0x3ba13fbd"
ATTRS{erase_size}=="512"
looking at parent device '/devices/platform/soc/3f202000.sdhost/mmc_host/mmc0':
KERNELS=="mmc0"
SUBSYSTEMS=="mmc_host"
DRIVERS==""
looking at parent device '/devices/platform/soc/3f202000.sdhost':
KERNELS=="3f202000.sdhost"
SUBSYSTEMS=="platform"
DRIVERS=="sdhost-bcm2835"
ATTRS{driver_override}=="(null)"
looking at parent device '/devices/platform/soc':
KERNELS=="soc"
SUBSYSTEMS=="platform"
DRIVERS==""
ATTRS{driver_override}=="(null)"
looking at parent device '/devices/platform':
KERNELS=="platform"
SUBSYSTEMS==""
DRIVERS==""
Meklon-Kitchen:~ # uptime -p
00:00:44 up 6 days, 14:22, load average: 0.05, 0.08, 0.07
Meklon, Ваш кухонный прибор за 158 часов прочитал примерно 71Мб и записал около 66Мб, т.е. он подпиливал SD-карточку со скоростью порядка 10Мб/сутки, это *на порядки* меньше, чем автомобильный регистратор. Если такой режим записи сохраняется всегда, то карточка должна прослужить достаточно долго, панику можно отложить:) Но недельная статистика может врать, попробуйте продержать систему месяц без перезагрузки и выполнить команду:
Делите на количество дней (часов), получаете среднесуточный износ, всё просто.
Я ещё обратил внимание, что соотношение чтение/запись почти 1:1 (т.е. карта «почти» не читается), что я считаю признаком SquashFS (она загружает содержимое ф/с в ОЗУ). У классических систем без SquashFS, как я понял из общения с другими читателями, соотношение где-то от 5:1 до 10:1. Чем бы там девайс не был занят на кухне, желаю приятного аппетита;))
cat /sys/block/mmcblk0/stat | awk '{printf "Uptime read: %.3fMiB written: %.3f MiB\n", $3*512/1048576, $7*512/1048576}'Uptime read: 71.982 MiB written: 65.856 MiBДелите на количество дней (часов), получаете среднесуточный износ, всё просто.
Я ещё обратил внимание, что соотношение чтение/запись почти 1:1 (т.е. карта «почти» не читается), что я считаю признаком SquashFS (она загружает содержимое ф/с в ОЗУ). У классических систем без SquashFS, как я понял из общения с другими читателями, соотношение где-то от 5:1 до 10:1. Чем бы там девайс не был занят на кухне, желаю приятного аппетита;))
Из приличных вроде
что-то последнее время хочется им добавить «не-». По крайней мере, купленным в более-менее крупных торговых сетях :(
На предмет «прибивания»: Консоль/root доступны? Для своего openHAB-а решил проблему через
mount --bind /opt/openhab/logs /mnt/sda/oh-logs
точнее — аналог этой строчки в fstab. Ну или симлинков наделать, но по мне, это менее надёжно при «отваливании» внешнего диска. Если памяти много и хранить не надо — tmpfs плюс пред-создание нужной структуры папок
Консоль доступна. fstab допилю, наверное. Логи я могу и в /dev/null, в принципе отправить. Это же не мой основной домашний сервер)
/dev/null хорошо для выбрасывания лишних логов.
Некоторые же утилиты хотят видеть конкретный файл и/или структуру папок на момент старта и начинают «чудить», если это не так.
у меня логи хранятся (не знаю зачем, привычка наверно), но /var/log живет на tmpfs с периодическим архивированием на флешку…
Некоторые же утилиты хотят видеть конкретный файл и/или структуру папок на момент старта и начинают «чудить», если это не так.
у меня логи хранятся (не знаю зачем, привычка наверно), но /var/log живет на tmpfs с периодическим архивированием на флешку…
как-то так
сам «сервис»
запускалка для systemd
Ну и в кроне (ещё не сподобился научиться крону от systemd)
#!/bin/sh
. /lib/lsb/init-functions
start() {
log_begin_msg "RAMLOG: Read files from disk.."
tar xfz /var/ram_log.tar.gz -C /
log_end_msg 0
}
stop() {
log_begin_msg "RAMLOG: Write files to disk.."
tar cfz /var/ram_log.tar.gz --directory=/ var/log/
log_end_msg 0
}
case "$1" in
start)
start
;;
stop)
stop
;;
flush)
stop
;;
*)
echo "Usage: $0 {start|stop|flush}"
exit 1
esac
запускалка для systemd
[Unit]
Description=Ramlog
After=local-fs.target
Before=cron.service syslog.service
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/opt/bin/ramlog start
ExecStop=/opt/bin/ramlog stop
[Install]
WantedBy=multi-user.target
Ну и в кроне (ещё не сподобился научиться крону от systemd)
0 */6 * * /opt/bin/ramlog flush &> /dev/null
#fstab
tmpfs /var/log tmpfs relatime,mode=1777
В принципе, до переполнения не должны забить память. Логично. Запишу в RAM.
Спасибо за комментарий, он навёл меня на мысль о том, куда лучше скидывать информацию, если не на флэшку:)
Скидывать лучше в облако, причём опытный ниндзя не будет использовать свой основной почтовый аккаунт. Конфиденциальные файлы (бэкапы настроек) перед отправкой в облако лучше зашифровать ассиметричным ключём, используя, например, команду openssl как-то так. Это позволит безопасно хранить публичную половину ключа
Ну а по поводу облака есть GDriveFS вообще и How to mount your google drive on Raspbian RPI with GDriveFS в частности.
Если информация достаточно безопасна, можно слать «периодику» по почте, но тогда желательно, чтобы её можно было читать сразу в почтовом клиенте, т.е. закладывать открытым текстом, без вложений. Искать гораздо удобнее, я пользуюсь для архивов S.M.A.R.T (у меня двенадцать 3.5" дисков в башне FreeNAS, и по каждому life time history в почте, это иногда очень выручает).
Скидывать лучше в облако, причём опытный ниндзя не будет использовать свой основной почтовый аккаунт. Конфиденциальные файлы (бэкапы настроек) перед отправкой в облако лучше зашифровать ассиметричным ключём, используя, например, команду openssl как-то так. Это позволит безопасно хранить публичную половину ключа
key.pub на каждом устройстве, не боясь, что кто-то сможет им вскрыть информацию (для этого нужен закрытый ключ;-)Ну а по поводу облака есть GDriveFS вообще и How to mount your google drive on Raspbian RPI with GDriveFS в частности.
Если информация достаточно безопасна, можно слать «периодику» по почте, но тогда желательно, чтобы её можно было читать сразу в почтовом клиенте, т.е. закладывать открытым текстом, без вложений. Искать гораздо удобнее, я пользуюсь для архивов S.M.A.R.T (у меня двенадцать 3.5" дисков в башне FreeNAS, и по каждому life time history в почте, это иногда очень выручает).
Какое гадство. openELEC не использует fstab!
А. Не, еще интереснее.
openelec uses a squashfs filesystem and is read-only at run time
Всё уже украдено до нас! © Root уже r/o — полдела сделано :)
А юзерские настройки он как-то хранит? Та же убунта замечательно хранит изменения поверх squashfs (casper-persistent кажется).
Не, уберджедаи могут «разобрать» squashfs, поправить и собрать обратно — как в кастомизации LiveCD.
Если есть откуда автоматом запустить скрипт, то остается «sudo mount --[r]bind /...»
А юзерские настройки он как-то хранит? Та же убунта замечательно хранит изменения поверх squashfs (casper-persistent кажется).
Не, уберджедаи могут «разобрать» squashfs, поправить и собрать обратно — как в кастомизации LiveCD.
Если есть откуда автоматом запустить скрипт, то остается «sudo mount --[r]bind /...»
Если флешка не китайское гуано — несколько лет помучается поработает без проблем. Моя три года прожила именно на openELEC+XBMC/KODI в ежедневноактивном режиме, пока не сдохла.
OpenELEC — довольно популярный дистрибутив. Может, кто посмотрит, что он на карту пишет :)
Может покажусь дилетантом, но:
внешний cd-rom с live-cd дистрибутивом?
внешний cd-rom с live-cd дистрибутивом?
А с ARM-архитектурой это возможно?
оптический привод по габаритам существенно превосходит одноплатный компьютер, не любит вибрации, нелепо выглядит, медленный, механический; но это близко к направлению SquashFS, которое я прокомментировал прямо в публикации, не стоит забывать о накладных расходах на изготовление образа firmware и обновлениях безопасности. Нужен адекватный community-проект, который будет публиковать обновления firmware и позволять их обновлять по сети, как это делают, например, OpenWRT и коммерческие производители. Это дорого.
Огромное спасибо за статью! У нас Raspberry используются вместе с висящими на стенами телевизорами для показа статуса Build-сервера, мониторинга и т.п. Каждые 8-12 месяцев приходится менять запиленную файловой системой SD-карточку.
Думается я 100% попадаю в целевую аудиторию Raspberry — деньги мы зарабатываем на технологиях далёких от Linux, и к Малинке обращаемся пару раз в год с дилетантскими задачами вроде «а как бы при старте автоматически запустить полноэкранный Chromium и открыть вот этот Url». Linux, увы, так и не выучил, а для малинки на любой вопрос можно выгуглить точный рецепт, причём из-за маленького зоопарка моделей рецепты четырёхлетней давности для Raspberry 1 обычно подходят и для Raspberry 3 (с GPIO чуть сложнее, но по сути надо различать всего две модели).
Особое спасибо за структуру статьи: описание проблемы/как будем решать/пошаговая инструкция. Это как раз на уровень знаний типичного пользователя малинки.
Пишите дальше в том же стиле, очень вам благодарен!
Думается я 100% попадаю в целевую аудиторию Raspberry — деньги мы зарабатываем на технологиях далёких от Linux, и к Малинке обращаемся пару раз в год с дилетантскими задачами вроде «а как бы при старте автоматически запустить полноэкранный Chromium и открыть вот этот Url». Linux, увы, так и не выучил, а для малинки на любой вопрос можно выгуглить точный рецепт, причём из-за маленького зоопарка моделей рецепты четырёхлетней давности для Raspberry 1 обычно подходят и для Raspberry 3 (с GPIO чуть сложнее, но по сути надо различать всего две модели).
Особое спасибо за структуру статьи: описание проблемы/как будем решать/пошаговая инструкция. Это как раз на уровень знаний типичного пользователя малинки.
Пишите дальше в том же стиле, очень вам благодарен!
Не знаю, что я делаю не так, у меня малинка работает как торрентокачалка на большой диск, в качестве сервера стоит Transmission, около двух лет работает. Я, правда, ее редко трогаю, но все же…
P.S. спаибо за статью, порадовался, что ГТ все еще ГТ.
P.S. спаибо за статью, порадовался, что ГТ все еще ГТ.
без графики и swap пара лет на нормальной флэшке — это вроде норма, как раз пора менять, может скоро сдохнуть:)
и благодарю за комплимент;)
Так в том то и дело! там все включено и иксы запущены! Трансмишен постоянно что-то раздает/получает.
а как флэшку зовут? есть возможность посмотреть
hdparm -I /dev/mmcblk0 Флешка smartbuy на 8 гигов а hdparm говорит invalid argument… Я не линуксоид, поэтому не знаю, что есть сие и как починить :)
прошу прощения, чинить ничего не надо
похоже, достаточно
там, правда, всё равно не понять ни рожна:)
похоже, достаточно
udevadm info -a -n /dev/mmcblk0 с правами rootтам, правда, всё равно не понять ни рожна:)
Действительно, непонять ни рожна… Судя по дате, работает, все же не два года, а с 07/15
как-то так
looking at device '/devices/platform/soc/3f300000.mmc/mmc_host/mmc0/mmc0:59b4/block/mmcblk0':
KERNEL==«mmcblk0»
SUBSYSTEM==«block»
DRIVER==""
ATTR{ro}==«0»
ATTR{size}==«15693824»
ATTR{stat}==" 608935 111823 59031459 11015680 753422 705684 13380833 23508600 0 6669180 34541880"
ATTR{range}==«32»
ATTR{discard_alignment}==«0»
ATTR{force_ro}==«0»
ATTR{ext_range}==«32»
ATTR{alignment_offset}==«0»
ATTR{inflight}==" 0 0"
ATTR{removable}==«0»
ATTR{capability}==«10»
looking at parent device '/devices/platform/soc/3f300000.mmc/mmc_host/mmc0/mmc0:59b4':
KERNELS==«mmc0:59b4»
SUBSYSTEMS==«mmc»
DRIVERS==«mmcblk»
ATTRS{cid}==«834e434e4361726402c2f10ca900f700»
ATTRS{csd}==«400e00325b5900003bdd7f800a400000»
ATTRS{scr}==«0235800300000000»
ATTRS{date}==«07/2015»
ATTRS{name}==«NCard»
ATTRS{type}==«SD»
ATTRS{preferred_erase_size}==«4194304»
ATTRS{fwrev}==«0x2»
ATTRS{hwrev}==«0x0»
ATTRS{oemid}==«0x4e43»
ATTRS{manfid}==«0x000083»
ATTRS{serial}==«0xc2f10ca9»
ATTRS{erase_size}==«512»
looking at parent device '/devices/platform/soc/3f300000.mmc/mmc_host/mmc0':
KERNELS==«mmc0»
SUBSYSTEMS==«mmc_host»
DRIVERS==""
looking at parent device '/devices/platform/soc/3f300000.mmc':
KERNELS==«3f300000.mmc»
SUBSYSTEMS==«platform»
DRIVERS==«mmc-bcm2835»
ATTRS{driver_override}=="(null)"
looking at parent device '/devices/platform/soc':
KERNELS==«soc»
SUBSYSTEMS==«platform»
DRIVERS==""
ATTRS{driver_override}=="(null)"
looking at parent device '/devices/platform':
KERNELS==«platform»
SUBSYSTEMS==""
DRIVERS==""
KERNEL==«mmcblk0»
SUBSYSTEM==«block»
DRIVER==""
ATTR{ro}==«0»
ATTR{size}==«15693824»
ATTR{stat}==" 608935 111823 59031459 11015680 753422 705684 13380833 23508600 0 6669180 34541880"
ATTR{range}==«32»
ATTR{discard_alignment}==«0»
ATTR{force_ro}==«0»
ATTR{ext_range}==«32»
ATTR{alignment_offset}==«0»
ATTR{inflight}==" 0 0"
ATTR{removable}==«0»
ATTR{capability}==«10»
looking at parent device '/devices/platform/soc/3f300000.mmc/mmc_host/mmc0/mmc0:59b4':
KERNELS==«mmc0:59b4»
SUBSYSTEMS==«mmc»
DRIVERS==«mmcblk»
ATTRS{cid}==«834e434e4361726402c2f10ca900f700»
ATTRS{csd}==«400e00325b5900003bdd7f800a400000»
ATTRS{scr}==«0235800300000000»
ATTRS{date}==«07/2015»
ATTRS{name}==«NCard»
ATTRS{type}==«SD»
ATTRS{preferred_erase_size}==«4194304»
ATTRS{fwrev}==«0x2»
ATTRS{hwrev}==«0x0»
ATTRS{oemid}==«0x4e43»
ATTRS{manfid}==«0x000083»
ATTRS{serial}==«0xc2f10ca9»
ATTRS{erase_size}==«512»
looking at parent device '/devices/platform/soc/3f300000.mmc/mmc_host/mmc0':
KERNELS==«mmc0»
SUBSYSTEMS==«mmc_host»
DRIVERS==""
looking at parent device '/devices/platform/soc/3f300000.mmc':
KERNELS==«3f300000.mmc»
SUBSYSTEMS==«platform»
DRIVERS==«mmc-bcm2835»
ATTRS{driver_override}=="(null)"
looking at parent device '/devices/platform/soc':
KERNELS==«soc»
SUBSYSTEMS==«platform»
DRIVERS==""
ATTRS{driver_override}=="(null)"
looking at parent device '/devices/platform':
KERNELS==«platform»
SUBSYSTEMS==""
DRIVERS==""
какой uptime у системы?
только что научился читать атрибут stat
только что научился читать атрибут stat
статистика с момента загрузки системы
соотношение чтение/запись у Вас почти 5/1read I/Os 608935 (requests) number of read I/Os processed
read merges 111823 (requests) number of read I/Os merged with in-queue I/O
read sectors 59031459 (sectors) number of sectors read
read ticks 11015680 (milliseconds) total wait time for read requests
write I/Os 753422 (requests) number of write I/Os processed
write merges 705684 (requests) number of write I/Os merged with in-queue I/O
write sectors 13380833 (sectors) number of sectors written
write ticks 23508600 (milliseconds) total wait time for write requests
in_flight 0 (requests) number of I/Os currently in flight
io_ticks 6669180 (milliseconds) total time this block device has been active
time_in_queue 34541880 (milliseconds) total wait time for all requests
read merges 111823 (requests) number of read I/Os merged with in-queue I/O
read sectors 59031459 (sectors) number of sectors read
read ticks 11015680 (milliseconds) total wait time for read requests
write I/Os 753422 (requests) number of write I/Os processed
write merges 705684 (requests) number of write I/Os merged with in-queue I/O
write sectors 13380833 (sectors) number of sectors written
write ticks 23508600 (milliseconds) total wait time for write requests
in_flight 0 (requests) number of I/Os currently in flight
io_ticks 6669180 (milliseconds) total time this block device has been active
time_in_queue 34541880 (milliseconds) total wait time for all requests
просто закомментировать его запуск в файле ~/.config/lxsession/LXDE/autostart. Если это не помогает, можно повесить по cron(8) с интервалом 718 минут команду xscreensaver-command -deactivate.
Т.е. мы отключили запуск скринсейвера вообще, но на всякий случай периодически его деактивируем?
Это как так???
Это стёб, дорогой читатель:) Вы же видите, как народ на полном серьёзе аппаратные USB-имитаторы мыши использует, вот я для таких ребят софтверный вариант предлагаю:)
В реальности же кто-то может ухитриться либо случайно запустить xscreensaver, либо отредактировать не тот файл, а завтра завозить оборудоание на выставку, в такой горячке сам кроном станешь. Я его, кстати, в пошаговой инструкции удаляю из системы, если заметили:
В реальности же кто-то может ухитриться либо случайно запустить xscreensaver, либо отредактировать не тот файл, а завтра завозить оборудоание на выставку, в такой горячке сам кроном станешь. Я его, кстати, в пошаговой инструкции удаляю из системы, если заметили:
apt-get remove --purge wolfram-engine triggerhappy cron anacron logrotate dphys-swapfile fake-hwclock Даже и не думал, что при использовании графики флешки летят так быстро. У меня Raspberry работает уже пару лет с флешкой, которая до этого стояла в телефоне, и никаких проблем нет. Постоянно запущены TOR, I2P, OpenVPN и XMPP-сервер Prosody. В феврале перевел её на f2fs, что дало ощутимый прирост в скорости работы всей системы.
прикольно, я даже не знал, что такая есть:)
спасибо, я добавлю в раздел «альтернативы»
спасибо, я добавлю в раздел «альтернативы»
SD карта — блочное устройство. Внутри в полноразмерной версии стоит NAND и контроллер, в микроверсии скорее всего чип, объединяющий обе функции, как eMMC. Контроллер скорее всего тоже в той или иной степени в зависимости от качества заточен под контроль степени износа. Возможно, даже, может использовать аналог мини файловой системы, обладающей качеством F2FS. Если бы карты делало добротно — то стандарт позволяет делать внутри значительный слой абстракций и решать проблему долгосрочной работы. Однако, наевшись последние несколько лет этой темы, я вижу, что в значительной степени большая часть карт — откровенный шлак, возможно даже контрафакт. Качественной карты практически не найти. Когда я отдельно закупал eMMC в Тайване, то скорость и долговечность работы отличались в несколько раз. Попытки использовать такое решение в режиме только на чтение — тогда уже лучше по старинке использовать NOR память, которая давно зарекомендовала себя в таком амплуа. Видя все это, я давно замечаю, как авторы «малинки» стабильно ложат болт в плане добавить в железо и в комплект то, что позволит повысить в этом месте надежность
Боюсь, Вы правы, дорогой читатель. Тот продавец, у которого я покупал пару лет назад TS2GUFM-V, именно такую грустную картину и пересказал: на онлайн-площадках один сплошной контрафакт. Такая версия хорошо бы объяснила, почему у одних система живёт два года, а у других два месяца, но практически это подтвердить тяжело в т.ч. из-за отсутствия аналога S.M.A.R.T и полной непрозрачности происходящего внутри SD-карточки. Именно поэтому я так обрадовался HPE Flash Media Kit.
И я тоже как-то прошёлся по данной теме в статье на хабре.
И я тоже как-то прошёлся по данной теме в статье на хабре.
СМАРТ мало у кого есть, но для андроида есть куча программ, которые показывают доп.инфо про внутреннюю и внешнюю флэш-память. Если предположить(!), что «шлак» и контрафакт не подделывают эту инфу, то на нее можно было бы опираться в выборе — но для этого нужно собирать статистику по отказам с учетом этой «скрытой» инфы.
я тут нашёл кое-какую команду:
но от неё немного пользы, она просто проходит по
у меня microSD SanDisk 32Гб 04/2014
интересный атрибут preferred_erase_size=4194304 и erase_size=512
udevadm info -a -n /dev/mmcblk0но от неё немного пользы, она просто проходит по
/sys/block/mmcblk0 и показывает всё, что нашла; однако что из этого относится к самой флэшке, а что является «ядерным суррогатом», я не могу сказатьу меня microSD SanDisk 32Гб 04/2014
интересный атрибут preferred_erase_size=4194304 и erase_size=512
далее — только цитаты по ссылкам
http://4pda.ru/forum/index.php?showtopic=712411
SD Insight
Последнее обновление 21.12.2015
Проверка параметров SD карты через SPI
Программа показывает производителя, серийный номер, дату производства, ёмкость и некоторую другую информацию, прописанную в контроллере SD карты. Также проверяется соответствие заявленных данных реальным (нужен доступ в интернет), что позволяет сделать приблизительные выводы об оригинальности карты.
http://4pda.ru/forum/index.php?showtopic=170318&view=findpost&p=42683000
Программа DiskInfo получает расширенную информацию о накопителе из директорий (для QCOM платформы):
/sys/devices/msm_sdcc.1/mmc_host/mmc0/mmc0:0001/
/sys/devices/msm_sdcc.2/mmc_host/mmc1/mmc1:aaaa/
В этой директории представлены следующие основные параметры: CID, CSD, date, fwrev, hwrev, manfid, name, oemid, serial, type.
для iNAND чипов информация об износе содержится в EXTCSD структуре, которую Android ядро не отображает в указанных директориях. Для получения данной структуры необходимо производить IOCTL запрос к устройству (к примеру /dev/block/mmcblk0), для чего требуются ROOT права.
Но с нуля писать код для считывания EXTCSD не нужно, т.к. этот функционал реализован в консольной утилите mmc-utils. Данную утилиту я уже дополнил командой, по которой структура EXTCSD выводится в сыром виде (просто 512 байтиков).
Исполняемый файл: mmc.zip ( 17,09 КБ ) — для скачивания надо залогиниться на 4пда
http://4pda.ru/forum/index.php?showtopic=712411
SD Insight
Последнее обновление 21.12.2015
Проверка параметров SD карты через SPI
Программа показывает производителя, серийный номер, дату производства, ёмкость и некоторую другую информацию, прописанную в контроллере SD карты. Также проверяется соответствие заявленных данных реальным (нужен доступ в интернет), что позволяет сделать приблизительные выводы об оригинальности карты.
http://4pda.ru/forum/index.php?showtopic=170318&view=findpost&p=42683000
Программа DiskInfo получает расширенную информацию о накопителе из директорий (для QCOM платформы):
/sys/devices/msm_sdcc.1/mmc_host/mmc0/mmc0:0001/
/sys/devices/msm_sdcc.2/mmc_host/mmc1/mmc1:aaaa/
В этой директории представлены следующие основные параметры: CID, CSD, date, fwrev, hwrev, manfid, name, oemid, serial, type.
для iNAND чипов информация об износе содержится в EXTCSD структуре, которую Android ядро не отображает в указанных директориях. Для получения данной структуры необходимо производить IOCTL запрос к устройству (к примеру /dev/block/mmcblk0), для чего требуются ROOT права.
Но с нуля писать код для считывания EXTCSD не нужно, т.к. этот функционал реализован в консольной утилите mmc-utils. Данную утилиту я уже дополнил командой, по которой структура EXTCSD выводится в сыром виде (просто 512 байтиков).
Исполняемый файл: mmc.zip ( 17,09 КБ ) — для скачивания надо залогиниться на 4пда
так, а вот командный интерфейс к EXTCSD (местный аналог SMART) — mmc-utils
осталось запустить его на Проге:)
осталось запустить его на Проге:)
ещё более интересная инфа содержится в первоисточнике: https://www.sdcard.org раздел загрузок, Simplified Specifications, Part 1 Simplified, Physical Layer Simplified Specification.
объект
stat: https://www.kernel.org/doc/Documentation/block/stat.txtраз мои ссылки вызвали интерес, то осмелюсь заявить, что при наличии «прямого доступа к диску» достаточно записать несколько коротких (а не в размер всей флэши) файлов, чтобы проверить наличие в контроллере и алгоритма размазывания, и TRIM.
Но я тут на птичьих правах и сама эта тема — все же почти оффтопик.
Т.е., если кто-то умеет программировать под чем угодно, умеет «прямой доступ к диску» и имеет там слот для SD card, то можно обсудить алгоритм такой простой(!) утилиты диагностики.
Т.е., я сам этого ничего не умею, научиться такому неспособен, а размещать подобные идеи в соотв. разделе 4пда смысла нет: опыт про СМАРТ на еММС по ссылке выше тому доказательство.
Но я тут на птичьих правах и сама эта тема — все же почти оффтопик.
Т.е., если кто-то умеет программировать под чем угодно, умеет «прямой доступ к диску» и имеет там слот для SD card, то можно обсудить алгоритм такой простой(!) утилиты диагностики.
Т.е., я сам этого ничего не умею, научиться такому неспособен, а размещать подобные идеи в соотв. разделе 4пда смысла нет: опыт про СМАРТ на еММС по ссылке выше тому доказательство.
… все уже украдено\сделано до нас!.. (с)
http://files.thecybershadow.net/trimcheck/
цитата:
TrimCheck provides an easy way to test whether TRIM works.
This program was written by Vladimir Panteleev.
You can find more information on the program's GitHub project page:
https://github.com/CyberShadow/trimcheck
http://files.thecybershadow.net/trimcheck/
цитата:
TrimCheck provides an easy way to test whether TRIM works.
This program was written by Vladimir Panteleev.
You can find more information on the program's GitHub project page:
https://github.com/CyberShadow/trimcheck
.
Для меня HPE Flash Media Kit — что-то новое, с виду очень интересное, надо обязательно попробовать
Wicron, Вы в курсе принципа работы SD Insight?
Это не серебряная пуля, но если выяснить, откуда она берёт инфу и как сравнивает, можно получить профит.
Это не серебряная пуля, но если выяснить, откуда она берёт инфу и как сравнивает, можно получить профит.
Изменяемая FS поверх неизменяемого имаджа — это то, что делает Docker. Надо гуглить в сторону AUFS и btrfs
Затем закомментируйте в fstab(5) строки, начинающиеся со слова mount_unionfs
Дилетантский вопрос: а не проще ли при обновлениях копировать содержимое /var в /var.orig? В этом случае ничего не надо перемонтировать, перезагружать, лазить в конфигурационные файлы и вообще можно не прерывать работы. Создать скриптик savechanges.sh, который будет скидывать данные с виртуальных дисков на реальные и вызывать его при обновлениях. Разве так нельзя сделать?
Предлагаемая мною имитация жизни в режиме read-write «с чистого листа» — перестраховка для тех, кто на «вы» с линуксами. Думаю, что можно обойтись и без неё, особенно, если устройство нежелательно перезагружать.
Но тогда и вся накопленная энтропия вместе с логами хлынет на SD-карточку и останется там условно навсегда. Я не исключаю также, что некоторый софт попытается сразу прописаться и в /etc, и в /home, и в /var, а если что-то не совпадёт, то надоедать ошибками. «Подложка» уже будет запорчена, придётся возиться.
Подкованный пользователь, конечно, выберет только самое необходимое из «нашлёпки» (и даже напишет скрипт для селективного сохранения в «подложке»), но для обычного пользователя это возня;)
Но тогда и вся накопленная энтропия вместе с логами хлынет на SD-карточку и останется там условно навсегда. Я не исключаю также, что некоторый софт попытается сразу прописаться и в /etc, и в /home, и в /var, а если что-то не совпадёт, то надоедать ошибками. «Подложка» уже будет запорчена, придётся возиться.
Подкованный пользователь, конечно, выберет только самое необходимое из «нашлёпки» (и даже напишет скрипт для селективного сохранения в «подложке»), но для обычного пользователя это возня;)
Если малинке нужен RTS то DS3231 на ebay где-то 1,5$, а если руками платку делать, то вероятно будет еще дешевле
о, спасибо, что напомнили, у меня их как раз валяется без дела две штуки, купленные по €0.73 (т.е. $1.5 за пару:)
готовое HOWTO можете порекомендовать для RPi? я понимаю, там ничего сложного вроде нет, но всё же
готовое HOWTO можете порекомендовать для RPi? я понимаю, там ничего сложного вроде нет, но всё же
конечно http://raspberrypi.ru/blog/598.html
конечно, Подключение RTC (часы реального времени) к Raspberry Pi
Установить время в RTC:
date --set=”20140125 09:17:00”
hwclock -w
При каждой загрузке системы необходимо в качестве системного времени, устанавливать время, сохранённое в RTC. Для этого пропишите в /etc/rc.local перед exit0 следующие команды:
echo ds3231 0x68 > /sys/class/i2c-adapter/i2c-1/new_device
hwclock -s
Опционально можно отключить синхронизацию системного времени через Интернет:
sudo update-rc.d ntp disable
Установить время в RTC:
date --set=”20140125 09:17:00”
hwclock -w
использую малину для управления насосами отопления в доме. Система отработала с сентября 2015 по июнь 2016 и с сентября 2016 работает по н.в.
Режим -раз в минуту считывает данные с ds18b20, включает-выключает насосы при необходимости, пишет все, что произошло, в лог. Раз в 3 часа записывается строка в файл со статистикой и файл отсылается по почте. Ну и по мере надобности, по команде через Телеграм, меняет целевые значения температур.
Графический режим не запускается.
Карта на 4 Гб, не помню какого производителя и класса, скорее всего Кингстон.
Режим -раз в минуту считывает данные с ds18b20, включает-выключает насосы при необходимости, пишет все, что произошло, в лог. Раз в 3 часа записывается строка в файл со статистикой и файл отсылается по почте. Ну и по мере надобности, по команде через Телеграм, меняет целевые значения температур.
Графический режим не запускается.
Карта на 4 Гб, не помню какого производителя и класса, скорее всего Кингстон.
Приветствую, evillexus! Судя по всему, Ваши отношения с различной пром. электроникой можно считать долгими и успешными, и система работает без графики, которая вынесена на смартфон:) Вы можете подержать систему без перезагрузки подольше и выполнить пару команд (root не требует):
Интересно, что скажет?
uptime -p
cat /sys/block/mmcblk0/stat | awk '{printf "Uptime read: %.3fMiB written: %.3f MiB\n", $3*512/1048576, $7*512/1048576}'Интересно, что скажет?
Приподниму некро-пост :).
Во-первых, в armbian появилось готовое решение для overlayfs с довольно приличной гибкостью (см. overlayroot)
А во-вторых в процессе возни с overlayroot на Pine64 образовалось интересное наблюдение: после неких действий с rw разделом (там это некая магия через chroot) или, что более вероятно, выполнении команды fstrim --all (штатно по крону раз в неделю) показания /sys/block/mmcblk0/stat сильно меняются.
Замечено было после резкого скачка записанного с 3Гб до 22.1Гб в stat, при том, что корневой раздел честно висит в r/o и времени на запись этих 19Гб было максимум 4 минуты. Для справки:
- полный объём раздела на SD — 24Гб
- занято 1.8Гб
- по сохранённым в перезагрузках показаниям stat записано 48.9Гб — глюк наблюдался дважды на примерно одинаковый объём
- по данным
dumpe2fs -h /dev/mmcblk0p1— 48Гб
Благодарю, дорогой читатель.
Что касается
Я полагаю, что никакой физической записи со скоростью ~80Мб/с в течение 4 минут, конечно, не было, и это даже *не* особенности реализации конкретного драйвера
Если всё вышесказанное верно, есть два вывода:
1) реальной записи не было, а карточку после прогона
2) метрики записи в
К сожалению, мне сложно сказать однозначно по поводу стандартизации такой процедуры чистки на всех моделях флэшек, это зависит от их прошивки, но для продления срока службы однозначно полезно, особенно с учётом примитивной реализации управления износа (очень далёкой от серверных SSD). Могу ошибаться в деталях, но общая картина выглядит непротиворечиво.
Что касается
armbian, то там сейчас нет и не планируется поддержка малинопрога, зато есть поддержка кучи других одноплатников. Для меня было полезно освежить портфель доступных решений на рынке. И спасибо за overlayroot, конечно.Я полагаю, что никакой физической записи со скоростью ~80Мб/с в течение 4 минут, конечно, не было, и это даже *не* особенности реализации конкретного драйвера
mmcblk в конкретном ядре. Рискну предположить, что fstrim --all просто записывала блоки нулей по всему незанятому пространству (24Гб за вычетом 1.8Гб примерно похоже на увиденные 19Гб). Драйвер всё это честно посчитал и отразил в stat. Микрокод флэшки же блок нулей воспринял как команду на освобождение и только обновил внутренние таблицы. Кто-то где-то писал, что так может (или должно быть?) на носителях, которые в явном виде TRIM не поддерживают, и что поддержку TRIM с помощью записи нулей как раз и можно отследить по аномально короткому времени транзакции. Такой же эффект можно получить с помощью dd, только нужно монтировать файловую систему в rw, а свободное пространство на короткий момент времени неизбежно сожмётся в точку. В промышленной системе даже короткая сингулярность доступного объёма может обернуться большими проблемами:)Если всё вышесказанное верно, есть два вывода:
1) реальной записи не было, а карточку после прогона
fstrim --all однозначно попустило, это как шлаки убрать из организма, простите за метафору:)2) метрики записи в
stat после такой чистки перестают иметь физический смысл, и ориентироваться на них более нельзя.К сожалению, мне сложно сказать однозначно по поводу стандартизации такой процедуры чистки на всех моделях флэшек, это зависит от их прошивки, но для продления срока службы однозначно полезно, особенно с учётом примитивной реализации управления износа (очень далёкой от серверных SSD). Могу ошибаться в деталях, но общая картина выглядит непротиворечиво.
Загуглил — overlayroot это вовсе даже часть ubuntu и доступно как отдельная репа — https://launchpad.net/ubuntu/xenial/+package/overlayroot. Из себя представляет пару скриптов для initramfs, конфиг и chroot-илку, для не-ubuntu можно качать и использовать "вручную"
Для меня его бонус в отсутсвии возни с ручной настройкой fstab/systemd — у меня часть данных на внешнем HDD, который не надо в overlay, хоть и ценой некоторого неудобства в chroot — там отрубается все, кроме "/", в том числе и /dev.
Утром перезагружал pine, проверил реакцию на fstrim --all — да, это оно. Время выполнения примерно 3.5 минуты, после чего stat выдаёт 21Гб записанных данных. Что характе́рно — если эту карточку воткнуть в кард-ридер ноутбука, оно пишет "trim не поддерживается".
Итого, сходимся на мысли, что верить stat-у нужно с оговорками, либо настраивать систему, чтобы fstrim не вызывался для read-only разделов и "не портил статистику" :)
ЗЫ: Да, повторный вызов fstrim --all через короткое время заканчивается быстро и не меняет (±несколько Мб) значения stat.
Спасибо за статью.
Пилю тонкий клиент на Pi 3.
Хочется нормальный человеческий android для Pi 3 с поддержкой.
Пилю тонкий клиент на Pi 3.
Хочется нормальный человеческий android для Pi 3 с поддержкой.
На здоровье, дорогой читатель. К слову: команда МалинПрога от Android открестилась, написав об этом FAQ на оф. сайте. Конечно, нет ничего невозможного, но стоит ли оно того?
6. WILL IT RUN ANDROID?Дескать, Android — потребительская платформа, а не дизайнерско-креативная игрушка для инженеров и энтузиастов. Пожалуй, да, хотя Google официально в этом не признается.
No. While a version of Android can be found in the forum, it is not stable enough for everyday use. There are no plans to continue working on it, as Android does not provide any enhancement to educational purposes that are not already fulfilled more readily with existing software – we see it as a platform for consumption, not creation.
Еще вот в єтом линухе так сделано хорошо.
Я сталкивался с єтой бордой, там, правда, не микро сд, а компакт флеш, но принцип тот же. Инструментарий єтого линуха "/" монтирует в rо, все папки для записи монтирует в ram, и оттуда, при вьіключении девайса, записьівает на флеш один раз за аптайм, так что и данньіе сохраняются, если нормально вьіключать.
После єтого, впервьіе столкнувшись с бананой, а потом и с малиной, бьіл очень-очень сильно удивлен, что все у них устроено не так, и флеш там пишут как у себя дома на блиньі хдд.
Я сталкивался с єтой бордой, там, правда, не микро сд, а компакт флеш, но принцип тот же. Инструментарий єтого линуха "/" монтирует в rо, все папки для записи монтирует в ram, и оттуда, при вьіключении девайса, записьівает на флеш один раз за аптайм, так что и данньіе сохраняются, если нормально вьіключать.
После єтого, впервьіе столкнувшись с бананой, а потом и с малиной, бьіл очень-очень сильно удивлен, что все у них устроено не так, и флеш там пишут как у себя дома на блиньі хдд.
Здравствуйте, дорогой читатель! Какой интересный и богатый у Вас орфографический стиль! Глядя на 'ы', я уж думал, у меня пиксел битый:) Сразу почему-то вспомнил печатную машинку «Адлер», приобретённую Остапом Бендером на базаре. У неё не хватало буквы 'е', и потому все переписка приобрела турецкий акцент (великий комбинатор использовал 'э' вместо 'е'). Я помню, под впечатлением от творчества Ильфа и Петрова даже вторгся в локализацию Windows 3.1 и заменил 'е' на 'э' во всех элементах GUI Program Manager. Бонус +15% к хорошему настроению на несколько дней получил (пэчать, отмэна, да/нэт, и т.д.). Тогда мир был другой, конечно.
Борда, кстати, неплоха: PoE, miniPCI, да и к Compact Flash у меня больше доверия. Но 256Мб ОЗУ сейчас маловато. А что касается встраиваемого линукса из Гонконга, то разработка, похоже, остановилась 1 мая 2015 года на версии 0.10.0. Жаль.
Борда, кстати, неплоха: PoE, miniPCI, да и к Compact Flash у меня больше доверия. Но 256Мб ОЗУ сейчас маловато. А что касается встраиваемого линукса из Гонконга, то разработка, похоже, остановилась 1 мая 2015 года на версии 0.10.0. Жаль.
Годная статья, спасибо автору. Поделюсь своей скромной статистикой. Собрал две торговых машины на мини-ПК от Olimex (того же плана пирожки, что и Raspberry). Поставил MicroSD карты Transcend 4GB. ОС — адаптированный Debian, c GUI. Никаких твиков по снижению износа карт не делал. Торговый софт на Python, на карту пишет логи (несколько десятков килобайт в сутки). В первой машинке карта продержалась год: система перестала загружаться, показывая чёрный экран малевича. Заменил карту на такую же. Замена прожила полгода: перестал запускаться торговый софт, при старте падал с ошибкой segmentation fault. Заменил на SanDisk Ultra 8GB на днях. Во второй машинке карта проработала полтора года, но я её для профилактики тоже заменил на SanDisk.
Ещё одна карта Transcend 4GB из той же партии умерла в Raspberry, который я дома время от времени использую для разработки. Система перестала загружаться, бесконечно плевалась сообщениями от fsck при загрузке. Выполнил запись нулей во все блоки виндовой утилитой flashnul, ею же прогнал полный тест — всё хорошо вроде бы. Перезалил образ. Система загрузилась, но развалилась через полчаса. Выбросил.
Ещё одна карта Transcend 4GB из той же партии умерла в Raspberry, который я дома время от времени использую для разработки. Система перестала загружаться, бесконечно плевалась сообщениями от fsck при загрузке. Выполнил запись нулей во все блоки виндовой утилитой flashnul, ею же прогнал полный тест — всё хорошо вроде бы. Перезалил образ. Система загрузилась, но развалилась через полчаса. Выбросил.
Спасибо, дорогой читатель. SanDisk — хороший выбор, если не контрафакт, конечно:)
Мне интересно, мои расчёты по
Я чувствую, нужно сделать утилиту для вытаскивания EXTCSD из SanDisk и написать отдельную статью про мониторинг износа SD-карточки для линукса вообще и RPi в частности. Интернет вещей грядёт, пораточить меч оттачивать инструментарий.
Мне интересно, мои расчёты по
stat (выше) совпадают с Вашей оценкой записи в сутки? Какой был uptime на устройствах в момент снятия udevadm info?Я чувствую, нужно сделать утилиту для вытаскивания EXTCSD из SanDisk и написать отдельную статью про мониторинг износа SD-карточки для линукса вообще и RPi в частности. Интернет вещей грядёт, пора
Малиновый Прог
<оффтоп>Ожидал прочитать что-то про King Crimson</оффтоп>
Спасибо за статью, заглянул в /sys/block/mmcblk0/stat и удивился, за месяц набежало 6гб записи, хотя логи и все изменения пишутся в tmpfs. Решил от греха подальше перемонтировать корень в ro, а в ответ получил "/ is busy", и неожиданно обнаружил виновника — /var/swap. Не смотря на настройку vm.swappiness=0 и то, что меньше, чем 400мб свободной памяти в системе за всё время с момента запуска системы не наблюдалось. swapoff решил проблему занятости корня, а fstab закрепил изменения.
Кстати, в таких условиях работы одна флешка умерла примерно за месяц работы. Можно сказать, что это личный антирекорд по времени жизни флешки.
Кстати, в таких условиях работы одна флешка умерла примерно за месяц работы. Можно сказать, что это личный антирекорд по времени жизни флешки.
Убить флеш за 6 ГБ как-то не очень. Совсем дохлая.
Согласен, но у меня был случай, когда за две недели убился 3Тб жёсткий диск WD Green (резко начала рости показатель Reallocated Sector Count, а потом диск просто исчез из системы), на него объём записи был ещё меньше. В магазине поменяли на такой же, лет 5 уже крутится 24/7, по smart выглядит живым. Флешка была SanDisk 8Gb class 10, сейчас Kingston с теми же цифрами установлен.
Meklon, мне только что пришла в голову одна (немного) тревожная мысль: я наивно упустил тот факт, что внутри флэшки пишется целиком *страница*, а не блок 512 байт. Поэтому при большом разбросе операций записи (в отличие от видеорегистратора, кстати) фактический расход ресурса будет кратный. Это заодно объясняет, почему при сбое питания всё может быть так плохо — микроконтроллер перед «закреплением» страницы ещё ждёт некоторое время (кэш на запись).
Параметр
Набрёл на интересное видео по поводу внутренностей «дешевых» флэшек: http://free-electrons.com/blog/elce-2011-videos/, см. доклад Arnd Bergmann, Optimizations for Cheap Flash Media
Но если 384Гб за месяц ушатывают флэшку до невменяемого состояния… Значит, просто износ очень неравномерный. А почему нет?
Параметр
preferred erase block size на 16Гб флэшках имеет размер 4Мб, но это (слава богу) не размер страницы, это размер «вычищаемого» под запись участка. Размер страницы неизвестен, но я, посмотрев видео (внизу), предполагаю его 32кБ на современных карточках. Это даёт уже другую математику. При самом неблагоприятном раскладе (100% разброс) фактически записалось не 6Гб, а 384Гб (6Гб x 32кб/512б = 6Гб x 64). Реальную степень «разброса» записи по страницам понять очень сложно, разве что смотреть на долю «writes merged», который в Вашем случае составил 7499/8963 = 84% (чем больше, тем запись «кучнее»).Набрёл на интересное видео по поводу внутренностей «дешевых» флэшек: http://free-electrons.com/blog/elce-2011-videos/, см. доклад Arnd Bergmann, Optimizations for Cheap Flash Media
Но если 384Гб за месяц ушатывают флэшку до невменяемого состояния… Значит, просто износ очень неравномерный. А почему нет?
В принципе, там действительно может быть очень тупой контроллер, который дырку протирает в одном месте.
из-за ограничений механизмов сборки мусора очень рандомная запись потенциально расходует целиком весь erase block (т.е. все 8Мб), а не одну страницу, т.е. при определённых (реальных) раскладах получается даже 1000-кратный расход ресурса записи:) это могло бы объяснить, почему за два месяца логи и swap способны ушатать даже аутентичную карточку SanDisk
см. https://wiki.linaro.org/WorkingGroups/KernelArchived/Projects/FlashCardSurvey
см. https://wiki.linaro.org/WorkingGroups/KernelArchived/Projects/FlashCardSurvey
кошмарики
постарался не вырывать фразы из контекста, но лучше, конечно, читать целиком
и далее:
Карточки оптимизируют логику под FAT32, но если используется EXT3/EXT4, всё не так хорошо:
а вот это вообще бомба:
Writing to random addresses on the medium will result in read-modify-write operation being performed on a whole allocation group, because each write access requires a garbage collection. For instance on a typical SDHC card with 4 MB erase blocks, a workload writing 4 KB file system blocks to completely random locations results in a write amplification factor of 1024.
и далее:
Only a small number of allocation groups is kept open at a time, on many SD cards only a single one, the largest observed number of open erase blocks was ten. Writing data to another allocation unit while having multiple units open causes the least recently used one to go through garbage collection. In the worst case, this can lead to the card writing a full allocation unit of multiple megabytes for each 512 byte block that gets written by the file system. All authentic Sandisk cards tested so far can write to six allocation units, and keep the most commonly written ones open, while most cheap cards have a smaller number and also use a simple one-stage least-recently-used algorithm for deciding with AU to clean up.
Карточки оптимизируют логику под FAT32, но если используется EXT3/EXT4, всё не так хорошо:
The cards take advantage of this knowledge by optimizing for the access patterns that are observed on FAT32, which unfortunately can lead to worst-case access patterns when using ext3 or other Linux file systems.
а вот это вообще бомба:
However, some CF cards are known to do static wear leveling in a way that leads to data loss when the supply voltage gets lost while the card is doing static wear leveling. This is even the case for read-only cards, since the static wear leveling can get triggered by read accesses on those cards.я так понимаю, что static wear leveling вроде как анахронизм уже
Еще Bergmann (2010-2011) — http://elinux.org/images/4/49/Elc2011_bergmann.pdf https://lwn.net/Articles/428584/
a5b, спасибо за статью! хорошо бы ещё понять, какие метрики можно снять из того же sysfs, как добраться до внутренних показателей карточки, не обвалив работающую с неё систему, и как это всё правильно трактовать
Некоторые подробности о контроллерах (в т.ч. фото) microsd — http://bunniefoo.com/bunnie/sdcard-30c3-pub.pdf http://www.bunniestudios.com/blog/?p=918 https://www.youtube.com/watch?v=CPEzLNh5YIo
Small embedded controller in every “managed Flash” device
– 8051 or ARM7 CPU
– 4-8mm^2 silicon = ~$0.15-$0.30 cost add-on
TLC/MLC Flash price is < 0.1nano$/bit
– Only achievable because every piece of silicon fabricated is sold, regardless of fabrication errors – nothing is thrown away
– Work around: bad block remapping
● In some cases, over 80% of blocks are bad (e.g. 16GiB chip sold as 2GiB)
– Also, blocks go bad with P/E cycles
Flash geometry changes every 12-18 mos
● New ECC rules
● New page size, block mapping
● Intensely cost-sensitive market
● Lowest cost, highest performing Flash chips are proprietary
What runs on the microcontroller? Can it be hacked? Can I trust my Flash memory?
… Fuzzing knock sequence
● 64 possible commands – Only 4 “manufacturer” commands – 2^32 possible arguments — No success
… Writing a debugger
… SD cards contain fully programmable microcontrollers
● Controller program modifiable via special host commands
DarkByte, приветствую! кстати,ilmarin77 уже комментировал выше параметр vm.swappiness, после чего мы обсудили noswap в /boot/cmdline.txt и снос dphys-swapfile
Может кому интересно — попалось упоминание про гибнущие карточки.
I now have 2 corrupted Transcend cards due to some unknown weird oPi issue. I have a rPi3 coming today and the oPi is going to be relegated to some other benign use. I'm hoping Transcend will RMA these cards.
Are you sure it is due to Orange Pi? Lot of people having RPi also have complaint of corrupted/worn out cards. I dont think this issue is related to make or model of Pi.
I have Pi B+, Pi 2, and OPi PC. None of my microSD cards have corrupted or worn out, though each card has several times faced formatting and fresh install.
One card came out of a Pi 2, the other was brand new. The Pi2 with an old card is still trucking and that is feeding to LiveATC.net 100% of the time with pretty good load. I think the oPi is also getting taxed when the reports/sec get above 400.
Благодарю за комментарий, но это относится к узкоспециальному софту FlightAware (который представляет собой в моём понимании телеметрическую линукс-обвязку к проекту dump1090 с добавлением графики). Износ SD-карточек определяется именно софтом: как и что именно записывается, в каком порядке, с каким разбросом, в каких объёмах, и т.д. Т.е. простая скалярная метрика «кол-во записанных блоков в сутки» характеризует износ не больше, чем средняя температура по больнице описывает здоровье пациентов, а при использовании другого софта (например, OpenELEC) картина фактического износа может быть совершенно другой, даже при одинаковой «плотности» записи в сутки.
Кстати, RPi3 официально поддерживает загрузку по USB: https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md
И, что актуально для этой статьи, загрузку через сеть: https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net.md
И, что актуально для этой статьи, загрузку через сеть: https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net.md
Спасибо.
Что касается загрузки по сети, появляется сильная зависимость от сервера-загрузчика. Ethernet сужает допустимую температуру экслуатации до 0-70C (ограничение микросхемы Ethernet-контроллера).
Автономность имеет и цену, и пользу, особенно с RPi. Одно-два устройства для «умного дома» вряд ли стоят целого сервера, а по сложности это то же самое, что разработать образ SquashFS и залить его на read-only microSD. Но я не говорю, что загрузка по сети — бесполезная функция, просто у неё должен быть определённый заказчик.
USB-накопитель неудобно торчит сбоку, либо требует кабеля, изменения корпуса. Вырастет и энергопотребление.
IMHO USB в RPi принципиально меняет картину только при использовании SSD-диска с интерфейсом USB, ценой примерно десятикратной (по сравнению с SSD) потери скорости и перехода на полудуплекс (ограничение USB 2.0). Но по сравнению с microSD разницы в скорости не будет:) Идея интересная, особенно если рассматривать SSD повышенной надёжности, но малой ёмкости. Найти их проще, чем качественную microSD. Однако при размещении системы на такой конструкции мы приходим… обратно к компактному десктопу, только медленному:)
В тех случаях, когда совершенно необходимо много записывать (СУБД), я бы всё равно использовал read-only microSD для системы и отдельный «пристяжной» SSD-накопитель для данных: алгоритмы сборки мусора и управления износом в SSD имеют совершенно другой порядок сложности. И нужен SMART, нужен TRIM, пройдёт ли это всё через USB?
У USB флэшек by design те же проблемы, что и microSD. Разве что из-за более крупных габаритов в USB-флэшку можно установить более износостойкие микросхемы, порой проще найти более дорогие и более «умные» USB-флэшки, чем microSD.
Про шпиндели в контексте RPi не упоминаю:)
Что касается загрузки по сети, появляется сильная зависимость от сервера-загрузчика. Ethernet сужает допустимую температуру экслуатации до 0-70C (ограничение микросхемы Ethernet-контроллера).
Автономность имеет и цену, и пользу, особенно с RPi. Одно-два устройства для «умного дома» вряд ли стоят целого сервера, а по сложности это то же самое, что разработать образ SquashFS и залить его на read-only microSD. Но я не говорю, что загрузка по сети — бесполезная функция, просто у неё должен быть определённый заказчик.
USB-накопитель неудобно торчит сбоку, либо требует кабеля, изменения корпуса. Вырастет и энергопотребление.
IMHO USB в RPi принципиально меняет картину только при использовании SSD-диска с интерфейсом USB, ценой примерно десятикратной (по сравнению с SSD) потери скорости и перехода на полудуплекс (ограничение USB 2.0). Но по сравнению с microSD разницы в скорости не будет:) Идея интересная, особенно если рассматривать SSD повышенной надёжности, но малой ёмкости. Найти их проще, чем качественную microSD. Однако при размещении системы на такой конструкции мы приходим… обратно к компактному десктопу, только медленному:)
В тех случаях, когда совершенно необходимо много записывать (СУБД), я бы всё равно использовал read-only microSD для системы и отдельный «пристяжной» SSD-накопитель для данных: алгоритмы сборки мусора и управления износом в SSD имеют совершенно другой порядок сложности. И нужен SMART, нужен TRIM, пройдёт ли это всё через USB?
У USB флэшек by design те же проблемы, что и microSD. Разве что из-за более крупных габаритов в USB-флэшку можно установить более износостойкие микросхемы, порой проще найти более дорогие и более «умные» USB-флэшки, чем microSD.
Про шпиндели в контексте RPi не упоминаю:)
В контексте статьи (создание сетевого устройства для отображения какой-то фиговины на мониторе через сеть) загрузка по сети как раз оптимальный вариант.
Кстати, https://habrahabr.ru/post/318486/ — тут тестировали диапазон рабочих температур малинки вместе с ethernet контроллером. Насколько я понимаю, как-раз Ethernet версия (Raspberry PI 2) работает от -45 до 105C, a Raspberry PI3 со связью через WiFi работала от -35 до 90C
Кстати, https://habrahabr.ru/post/318486/ — тут тестировали диапазон рабочих температур малинки вместе с ethernet контроллером. Насколько я понимаю, как-раз Ethernet версия (Raspberry PI 2) работает от -45 до 105C, a Raspberry PI3 со связью через WiFi работала от -35 до 90C
создание сетевого устройства для отображения какой-то фиговины на мониторе через сетьскорее, создание многих сетевых устройств для отображения каких-то фиговин на многих мониторах через сеть, ради одного монитора лично я это громоздить не стану:) но да, согласен, я и не отказываюсь добавить Ваше предложение в альтернативы, только чуть позже это сделаю. Кстати, отказ от microSD в пользу загрузки по сети м.б. обоснован и тем, что microSD от холода или жары может «сдохнуть» гораздо быстрее, чем компоненты.
Ethernet версия (Raspberry PI 2) работает от -45 до 105C, a Raspberry PI3 со связью через WiFi работала от -35 до 90Cпо официальным данным, температуру ограничивает именно LAN9512, который в коммерческом (не индустриальном LAN9512i) варианте имеет 0-70C по datasheet. На моей RPi установлен LAN9514. Есть, как минимум, две причины ставить на Прог коммерческую версию: (1) стоимость и (2) потенциальные экспортные ограничения на продукцию «двойного» назначения. Я, конечно, заморачиваюсь, и RPi, конечно, может работать в более широком диапазоне. И спасибо за ссылку, я с удовольствием укажу ребятам на кое-какие факты и пробелы.
Спасибо за подробную статью! Одно дополнение — systemd умеет сам управлять watchdog. Минус — при использовании этого метода пропадает любая возможность контроля состояния watchdog, так как устройство захватывается (то есть wdctl уже ничего не скажет), а клиентской утилиты для watchdog systemd (пока?) не имеет
Вот кстати очень похожая статья на хабре
https://habr.com/ru/post/470519/
Thanks for the post. UnionFS is used in Docker, I knew about that, but never thought of this kind of application for it :)
To me, the idea of making your whole SBC Linux device to trash whatever you were doing with reboot/restart definetely has something in it, but it doesn't fit very well for "desktop replacement" use cases. Because the burden of keeping all this extra entropy is lying on RAM shoulders. And we all know what happens when your system is running out of RAM.
I did the orthogonal thing - just "debloated" linux from whatever extra stuff it was doing (apt/dpkg updates&upgrades&maintenance), found those bastards who were writing the most to my lovely SD card and dealt with them, one by one.
I don't have exact stats at hands, like how much writes would there be on SD over a week of uptime, because I just finished this process, and still have some small outliers I need to handle. But if anyone is interested, here's what I've done - https://orange-pi-4-lts.blogspot.com/2022/08/debloating-your-linux-even-further.html
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Малиновый Прог против Интернета Кирпичей, или Raspberry Pi с графикой на read-only microSD