Какая файловая система наиболее устойчива к сбоям?
ОБНОВЛЕНО!
Гипотетическая ситуация:
В офисе вечерами работает программист Петя. Он сейчас сидит и непосредственно пишет код. В vscode.
Также в офис приходит электрик Вася, которому нужно сделать свою работу. Вася дергает не тот рубильник, комп Пети обесточивается...
Еще одна гипотетическая ситуация: (потому что все ожидаемо начали советовать ставить упсы и циклиться на пропадании питания)
Секретарша Маша при попытке вставить флэшку в разьем нажимает кнопку ресета в то время, как у нее открыто на редактировании куча документов.
ИЛИ
Программист Коля, которого недавно пересадили с винды, по виндовой привычке решать все ребутом, с чего-то решает, что линух завис и топит ресет в процессе работы.
Знакомо, да?
Вопрос - в какую файловую систему разметить диск и какие задать параметры монтирования (а также точные настройки через sysctl, комстроку ядра и пр.), чтобы не узреть cannot read superblock?
(Вопрос можно поставить шире - что еще можно придумать, чтобы при ресете не рушились файловые системы?)
Прошу не уходить в сторону "купить и поставить UPS". Интересует именно опыт использования ФС по части стабильности.
(Зачем: после замены обычных винтов на ssd я заметил, что куда-то делась знаменитая линуховая стабильность ФС, когда можно было рубить сервак в любом состоянии... Я понимаю, что дело не в ssd, а в моей криворукости, что наверняка есть нужные настройки)
В общем-то, напрасно. Десктопные модели в угоду себестоимости и маркетинга (как бы нарисовать производительность повыше в бенчмарках) довольно вольно обращаются с гарантиями durability которые должны бы обеспечивать. Например, когда файловой системе отчитались flush, а на самом деле контроллер SSD ещё не записал все данные во flash, а только в буфер (или вовсе лишь только в HMB в случае nvme) и который даже не прикрыт конденсатором, позволяющим корректно дописать всё что уже пообещали при внезапном отключении питания.
Drno, Вопрос о выборе ФС :) настройках монтирования и всего того, что можно покрутить через sysctl и ведро. Потому что ситуация не поменялась, за исключением того, что hdd сменился на ssd, а устойчивость к сбоям куда-то делась. Понятно, что я просто что-то не включил/не выключил/не установил/не настроил. Вопрос - что?
Melkij, Хм. То есть ситуация , как с raid-контроллером без батарейки? "Наверх" уже ушло, что данные записаны, "внизу" они еще только пишутся и, если топануть фазу - мы и выловим рассогласование кэша?
Есть способы это настроить как-нибудь (даже ценой производительности)?
угу, ситуация полностью аналогично контроллеру с writeback кэшом без батарейки. С точки зрения именно ОС на это не повлиять, сама команда flush (недвусмысленно именованная FLUSH CACHE в ATA и аналоги в прочих стандартах) и должна была собой гарантировать, что данные реально дошли до постоянной памяти. А если по умыслу или ошибке такой гарантии нет - то ОС об этом даже не может узнать.
Можно поискать нет ли управляющих команд для конкретных SSD (по типу вендорской утилиты настроек рейд-контроллера для переключения cache mode), но я сомневаюсь в благополучном исходе.
Маркетинг и жажда власти уже породили термин Power Loss Protection, которым производители SSD хвалятся на своих дорогих моделях. А пытаться какими-то настройками спасать дешманские, похоже, просто бесполезно.
Adamos, ну вот, что нашлось:
"To protect all data, regardless of any power supply problems, users should choose the SSD product that supports PLP. When the SSD is powered on, PLP capacitors start to charge the current and, if external power is off for any reason, the charged current in the capacitors starts to discharge to offer additional power (current) to the SSD. This process holds the DRAM data and allocates time for the data flush from the DRAM to the NAND to occur, updating the latest data. This flushing task should be completed within the discharging time."
CityCat4, я там видел еще что-то про ограничение записи при проседании напряжения - в ожидании, что щас придется скидывать кэш, диск уже не дает в него писать. Может выйти неожиданным боком в реальных условиях, особенно без выравнивания линии UPS-ом. Или при хреновом БП. В общем, оно делается не под условия рабочей станции, а больше под всякую встройку.
ага, именно что типа батарейка. Схематически, на сколько знаю, там действительно конденсатор.
про ограничение записи в зависимости от напряжения не слышал, но в общем возможно. Для нас ведь прошивка - чёрный ящик...
Также в офис приходит электрик Вася, которому нужно сделать свою работу. Вася дергает не тот рубильник, комп Пети обесточивается...
Бесперебойник, либо пусть Петя на ноуте работает.
Секретарша Маша при попытке вставить флэшку в разьем нажимает кнопку ресета в то время, как у нее открыто на редактировании куча документов.
Пусть секретарша пользуется облачными сервисами типа гугл-документов или аналогичным в рамках локальной сети.
Запретить перезагрузку по кнопке.
Программист Коля, которого недавно пересадили с винды, по виндовой привычке решать все ребутом, с чего-то решает, что линух завис и топит ресет в процессе работы.
А что программист Коля не умеет гитом пользоваться?
Иерокопус Таманский, на том же SSD, у которого при резком выключении пропадает всякая мелочь, записанная в кэш, но не слитая в ячейки памяти самого диска. В том числе временные файлы VCS. Речь же не про то, что кто-то что-то не сохраняет, а про то, что сохранение еще не означает реальную запись.
Иерокопус Таманский, Только если у него временные файлы хранятся на другом диске, например. Потому что если они тоже здесь - они точно так же пропадут.
CityCat4, Melkij, наткнулся тут на директивы отключения дискового кеша для sata ssd и nvme что по идее должно частично решить вопрос с битой файловой системой за счёт ожидания фс завершения записи
Понимаю что от ресета точно не спасет как и от отключения света а также замедлит io системы
