CityCat4
@CityCat4
//COPY01 EXEC PGM=IEBGENER

Какая файловая система наиболее устойчива к сбоям?

ОБНОВЛЕНО!
Гипотетическая ситуация:
В офисе вечерами работает программист Петя. Он сейчас сидит и непосредственно пишет код. В vscode.
Также в офис приходит электрик Вася, которому нужно сделать свою работу. Вася дергает не тот рубильник, комп Пети обесточивается...

Еще одна гипотетическая ситуация: (потому что все ожидаемо начали советовать ставить упсы и циклиться на пропадании питания)
Секретарша Маша при попытке вставить флэшку в разьем нажимает кнопку ресета в то время, как у нее открыто на редактировании куча документов.
ИЛИ
Программист Коля, которого недавно пересадили с винды, по виндовой привычке решать все ребутом, с чего-то решает, что линух завис и топит ресет в процессе работы.

Знакомо, да?

Вопрос - в какую файловую систему разметить диск и какие задать параметры монтирования (а также точные настройки через sysctl, комстроку ядра и пр.), чтобы не узреть cannot read superblock?
(Вопрос можно поставить шире - что еще можно придумать, чтобы при ресете не рушились файловые системы?)

Прошу не уходить в сторону "купить и поставить UPS". Интересует именно опыт использования ФС по части стабильности.

(Зачем: после замены обычных винтов на ssd я заметил, что куда-то делась знаменитая линуховая стабильность ФС, когда можно было рубить сервак в любом состоянии... Я понимаю, что дело не в ssd, а в моей криворукости, что наверняка есть нужные настройки)
  • Вопрос задан
  • 603 просмотра
Решения вопроса 1
@rPman
Ваша задача решается только аппаратными средствами. При ненадежном окружении машину нужно буквально выносить на расстояние, подальше от этого окружения (т.е. у клиента только монитор+клавиатура а редактировать документы на флешках запретить, я серьезно), это реально и не так дорого как кажется, но все же необходимо обеспечить место где железо не будет зависеть от электрика Васи и 'супер-чайника бабы Глаши'.

На самом деле тут несколько проблем, каждая из которых решается разными способами:
* сбои в железе, т.е. буквально смерть диска или флешки (нельзя на них работать, никак нельзя), в частых случаях это решают резервированием, спасибо для дисков существует RAID5, когда за счет добавление 1 диска к массиву (начиная с 3 дисков до 32 шт) обеспечивает работоспособность при потере любого 1 диска, а при добавлении 2-ух дисков, соответственно переживает потерю любых двух дисков.
* сбои в электропитании - качественный бесперебойник и настройка на автоматическое сохранение работы. Система резервного электропитания - отдельный большой разговор и дешевым это не будет, в зависимости от того, какие бывают сбои, может оказаться что единственный вариант - дорогой online ups + дизельный генератор.
Для рабочих windows и иногда и linux можно настроить hibernation по сигналу с UPS, это как минимум спасет не только файловую систему но и не сохраненную работу.
Так же есть механизмы у систем виртуализации, если гостевая операционная система не умеет hibernation, то это сможет сделать сервер виртуальной машины (кажется любой)
* сбои в софте и кривые руки пользователя - самый интересный сбой, когда по ошибке одним движением пользователь уничтожает важные данные, ошибка конфигурации отправляет базу в ноль или безвозвратно портит данные. На это тоже есть два решения, в обычном случае это регулярные бакапы, причем если есть база данных то можно сделать очень оперативный инкрементальный бакап прямо средствами БД (что то типа прерванной репликации например) и регулярные снапшоты (как еще одна форма бакапа, только не покидающая машину).
И вот тут выбор файловой системы может сильно помочь, например cow fs типа btrfs или zfs умеют делать снапшоты бесплатно, без деградации скорости работы (до этого был lvm но его снапшоты кратно! замедляли запись, пока снапшот не удалишь), у windows ntfs тоже есть shadow copy но там какие то особенности есть, не делающие это чистым снапшотом, т.е. пользовательские файлы так резервируются а система не всегда, ну через нее делают бакап перед установкой обновлений.
Можно настроить буквально поминутные снапшоты с удалением тех что старее часа/суток/... и фоновым переносом их на бакап сервер, т.е. это сочетание системы резервного регулярного и оперативного копирования
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 7
Alex_Geer
@Alex_Geer
System Engineer
Нужно смотреть на файловые системы с журналированием. Например XFS или ext4
Что это такое: https://www.interface.ru/home.asp?artId=18352
Как включить журналирование например на ext4 гуглится легко.
Ответ написан
mayton2019
@mayton2019
Bigdata Engineer
Современное ПО очень сложное в части гарантий сохранения транзакций например. В БД для того чтобы
сохранился commit, мы должны гарантировать что за секунду до аварии мы успели сделать FSYNC
для всех буферных операци I/O.

И эта проблема никак не решается заменой одной ФС на другую. Вы пишите хоть в ZFS, хоть в RAW,
но здесь эта гарантия дает сбой. База не смогла сохранить последний коммит. И при recovery будет
откат транзакций назад. И дальше надо на уровне приложений разбираться где какие платежи не прошли
и кому вернуть деньги.

Поэтому сервак БД должен быть хотя-бы застабилизирован на 5-10 минут чтобы успеть корректно сделать
shutdown. Либо дежурный админ это сделает либо ваш софт - неважно. Тоесть отключение энергии должно
быть плановым и контролируемым.

По поводу cannot read superblock - не знаю. Я такого в своей практике никогда не встречал. Надо поисследовать
вопрос глубже. Предполагаю что это не сама причина а следствие чего-то другого. Например виртуальные машины не нашли свою файловую систему.
Ответ написан
@Bwana
Самый надежный вариант не потерять набранное -- Ctrl-S перед каждой паузой в процессе набора/редактирования. Через какое-то время это станет бессознательным действием и случаи потерь сократятся до одного-двух в квартал.
Главное, не выключать комп без необходимости -- достаточно вырубать мониторы и все.
Ну и классические бекапы перед уход домой. Это если внезапно комп/диск сдохнет.
Проверено на себе и уже лет надцать не подводит. Храню только последний (вчерашний) бекап. В нескольких местах, в том числе и на флешке в кармане.
Ответ написан
Комментировать
VoidVolker
@VoidVolker
Dark side eye. А у нас печеньки! А у вас?
Вопрос - в какую файловую систему разметить диск...

В любую. Если вам нужная защита от сбоя по питанию - то надо именно эту проблему и решать, а не её последствия. И самое простое решения - это источник бесперебойного питания. В качестве альтернативы можно работать с ноутбука или подключаясь к удаленному серверу в ЦОД. Ибо кроме ФС есть еще куча других факторов типа ОС, драйверов, оборудования и их нюансов работы. ФС - лишь составная часть, одна "из".

когда можно было рубить сервак в любом состоянии...

Сервера должны работать через ИБП, должно быть реализовано резервирование линий питания, блоков питания, есть даже рейд контроллеры со своими аккумуляторами. И еще куча других мер. Т.е., должно быть применено комплексное решение по минимизации ущерба в случае того или иного сбоя в том или ином месте. И "рубить сервак" - это уже крайняя мера, когда у вас не осталось других методов взаимодействия с сервером. А значит, что-то было сделано/организовано не так, как должно быть.
Не следует путать устойчивость к сбоям для сервера и для домашнего ПК - это несколько разные вещи с разными требованиями.
Ответ написан
dimonchik2013
@dimonchik2013
non progredi est regredi
ну, рекламно Btrfs , где-то там еще Zfs ходит
а еще JFS есть
а практически окажется что обычная ext4вполне себе

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

я (мы, с админами/девопсами) решали задачу хранения отдачи множества мелких файлов - меня интересовало с т.з. экономики - меньше серверов проще говор - а админов с т.з. намыленной *опы, и там все эти *fs перебирались, оказалось -везде что-то не так - то ли партицирование, то ли рейд не строится, то ли что-то еще

в итоге остановились на уче4 и seaweedfs поверх - да, это не ФС в обычном виде, но - такая была задача

думаю, и сами знаете - изучить отзывы а дальше - только эксперимент, потому что отзывы-опыт тоже зависит от окружения на моменте - например, хард рейд и т.п.
Ответ написан
Комментировать
saboteur_kiev
@saboteur_kiev Куратор тега Linux
software engineer
все очень просто.
1. Бэкапы.
2. УПС.

И не искать себе выдуманное решение с файловыми системами.
* Файловые системы не заботятся о пользовательских данных.
* Целостность файловой системы это о том, что структура будет целая, то есть два файла не занимают один кластер, нет незавершенных операций, когда что-то недописано, или какой-то кластер считается занятым, а на самом деле нет и уже неконсистентность.
* Эти проблемы решаются простым способом - все что криво удалить, и все. Не восстановить.
* Второй момент - софт может просто записать кривые данные, и тут как бы от файловой системы не зависит. Вплоть до какого-нить криптера, который сделает совершенно корректные файловые операции и все пошифрует.
* Если же глючит хард, то там все еще хуже.

Поэтому вместо поиска велосипедов на низкоуровневых проблемах, просто делайте регулярные бэкапы, и если что-то подобное случится, то да, пользователь потеряет часть работы, от последнего бэкапа.
Бэкапы хранить на отдельной машине, доступ к ним ограничить отдельным паролем, на машину УПС, можно еще и рейд.
Ответ написан
Используя Linux, SSD с ext4, VS Code и имея частые отключения электроэнергии в электрощите, могу с уверенностью утверждать, что файлы не бьются и открываются без проблем ровно в том месте, где не закончил редактирование кода. Также выработана привычка нажимать Ctrl-S чуть ли не при любом изменении, даже мало-мальском.
P.S. планирую купить UPS.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы