Неоднократно сталкивался с повреждением файловой системы на Linux разных версий.
Иногда удавалось восстановить иногда нет.
Бывало после отключения электричества, бывало не с того не с сего.
На Windows таких проблем меньше.
Насколько устойчива и защищена файловая система Linux по сравнению с Windows?
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, igor-booch, Вы писали:
IB>Неоднократно сталкивался с повреждением файловой системы на Linux разных версий. IB>Насколько устойчива и защищена файловая система Linux по сравнению с Windows?
Смотря какая файловая система — журналируемые должны восстанавливаться.
Если btrfs, то вроде как она и не стала стабильной.
xfs должна работать нормально, но лично я сталкивался с повреждением в виртуалках centos, в которых она по умолчанию. После замены на ext4fs виртуалки стали работать нормально. Что было с xfs не разбирался.
Так что в целом мейнстрим журналируемые файловые системы надежны, если никаких особенных фич не надо, попробуй старый добрый ext4.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, igor-booch, Вы писали:
IB>Неоднократно сталкивался с повреждением файловой системы на Linux разных версий. IB>Иногда удавалось восстановить иногда нет. IB>Бывало после отключения электричества, бывало не с того не с сего. IB>На Windows таких проблем меньше. IB>Насколько устойчива и защищена файловая система Linux по сравнению с Windows?
Я принимал участие в разработке прибора с Linux на борту, который штатно выключался
отключением от электросети. То есть никаких "Linux выключается, пожалуйста подождите",
выдернули из розетки и все. Там в том числе был и R/W раздел, и вот уже несколько
лет в эксплуатации и проблем именно с ФС никаких нет.
Здравствуйте, Zhendos, Вы писали:
Z>Я принимал участие в разработке прибора с Linux на борту, который штатно отключался Z>отключение от электросети. То есть никаких "Linux выключается, пожалуйста подождите", Z>выдернули из розетки и все. Там в том числе был и RW раздел, и вот уже несколько Z>лет в эксплуатации и проблем именно с ФС никаких нет.
Я даже знаю, как такой прибор сделать — буферизовать питание конденсатором или ионистором для устройства, на которое пишем, чтобы гарантировать запись его очереди.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, Zhendos, Вы писали:
Z>>Я принимал участие в разработке прибора с Linux на борту, который штатно отключался Z>>отключение от электросети. То есть никаких "Linux выключается, пожалуйста подождите", Z>>выдернули из розетки и все. Там в том числе был и RW раздел, и вот уже несколько Z>>лет в эксплуатации и проблем именно с ФС никаких нет.
Ops>Я даже знаю, как такой прибор сделать — буферизовать питание конденсатором или ионистором для устройства, на которое пишем, чтобы гарантировать запись его очереди.
Ничего такого не делали.
Там пишутся логи, потеря данных за последнюю минуту не критична.
Поэтому никакой батарейки и обратной связи об отключении питания не было.
Здравствуйте, Zhendos, Вы писали:
Z>Ничего такого не делали. Z>Там пишутся логи, потеря данных за последнюю минуту не критична. Z>Поэтому никакой батарейки и обратной связи об отключении питания не было.
Видимо, маленький объем. Когда в буфере на запись много блоков ждет своей очереди, может и ФС попортиться.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, Zhendos, Вы писали:
Ops>Видимо, маленький объем. Когда в буфере на запись много блоков ждет своей очереди, может и ФС попортиться.
С чего-то это вдруг ей портиться в зависимости от количество блоков ждущих записи?
Здравствуйте, Zhendos, Вы писали:
Z>Здравствуйте, Ops, Вы писали:
Ops>>Здравствуйте, Zhendos, Вы писали:
Ops>>Видимо, маленький объем. Когда в буфере на запись много блоков ждет своей очереди, может и ФС попортиться.
Z>С чего-то это вдруг ей портиться в зависимости от количество блоков ждущих записи?
Или вы подрузумеваете что в приборе будет некий ПЗУ с кэшем,
который скажет ядру Linux что все записано, но на самом деле данные будут в кэше?
Но это было бы довольно странно ставить такой ПЗУ в прибор с такими требованиями.
Здравствуйте, Ops, Вы писали:
Z>>С чего-то это вдруг ей портиться в зависимости от количество блоков ждущих записи?
Ops>Невозможно записать 2 разных блока атомарно. Если это блоки с метаданными, то нарушится их целостность.
Именно метаданные сейчас журналируются по умолчанию (на ext4 и подобных).
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, Zhendos, Вы писали:
Z>>С чего-то это вдруг ей портиться в зависимости от количество блоков ждущих записи?
Ops>Невозможно записать 2 разных блока атомарно. Если это блоки с метаданными, то нарушится их целостность.
Ну и что, что нельзя записать два блока атомарно, почему современная (да и не современная)
журналируемая ФС не сможет это учесть? Метаданные же сначала пишутся в журнал,
потом переносятся в основную ФС, потом ставиться отметка сделано, ничего из этого вроде не требует
атомарно писать два блока?
Здравствуйте, igor-booch, Вы писали:
IB>Неоднократно сталкивался с повреждением файловой системы на Linux разных версий. IB>Иногда удавалось восстановить иногда нет. IB>Бывало после отключения электричества, бывало не с того не с сего. IB>На Windows таких проблем меньше. IB>Насколько устойчива и защищена файловая система Linux по сравнению с Windows?
По моим наблюдениям, как минимум ext4 не предназначена для резкого отключения питания — как минимум, пропадают файлы, как максимум root fs вообще не монтируется, и получается boot loop (причем встроенный fsck по какой то причине (не разбирался по какой) не запускается, и приходится вытаскивать hdd, подключать к другому компу, прогонять проверку и восстановление fs на другой, что добавляет гемора. (Возможно zfs получше? Не знаю.) На одноплатных компьютерах, вроде raspberry pi, это беда, при резком пропадании питания высока вероятность, что он в след. раз не запустится.
Ни на Windows с их ntfs, ни на Mac с их apfs/hfs+ такого не наблюдал. Схожие с линуксом проблемы встречал только на Win98 с их FAT32.
Здравствуйте, igor-booch, Вы писали:
IB>Насколько устойчива и защищена файловая система Linux по сравнению с Windows?
Этих ФС там десятки — какая из них? Впрочем, неважно. Главное — NTFS разработана коммерческими девами, а в Линупсах всё на энтузазизме.
Когда я по молодости с горящими глазами разбирался с Линуксом, даже техническое описание ext2 вводило в уныние "Да чего так сложно-то??".
Мне кажется, яйцеголовые девелоперы слишком тупо подходят к самому принципу разработки:
-Давайте сделаем всемогутер на палках!
-А вдруг там ещё будут флэшки??
-Ладно — и на изоленте!
Вот из-за этой бестолковой "универсальности" и получаются монстры файловой словесности.
ОС у нас одна, но задач у неё много и под каждую из них надо делать свою надёжную ФС.
Загрузка: она может идти с ПЗУ, с флэшки (которую желательно лишний раз не дрючить), с харда, но факт тот, что это наименее изменяемая часть системы. Соотв. туда можно вкорячить что-то вроде SquashFS. Загрузились — посыпались логи. Очевидно, что под "массовая запись маленькими порциями" нужна отдельная FS (не знаю, может такая и есть уже давно). Юзерские файлы — они самые важные, там нужна ФС с самым надёжным механизмом — чексуммы, восстановление неверных битов, зеркалирование, атомарность и т.п.
Глупо собирать все эти вещи в одну ФС — должно быть разделение ФС по свойствам. Тогда и загрузка будет не по минуте, а как в БК0010 — ДВЕ секунды от нажатия power!
Живём в век гигабайтных скоростей (у меня вот например SSD 3.5ГБ/с), но на венде от этого вообще никакого толку.
Здравствуйте, Kolesiki, Вы писали:
K>Здравствуйте, igor-booch, Вы писали:
IB>>Насколько устойчива и защищена файловая система Linux по сравнению с Windows?
K>Этих ФС там десятки — какая из них? Впрочем, неважно. Главное — NTFS разработана коммерческими девами, а в Линупсах всё на энтузазизме.
На каком энтузиазме, все ключевые разработчики ext 3-4 работают
в Google, IBM, RedHat и т.д. и т.п., назовите хотя бы одного из ключевых разработчиков
ext 3-4 который не занимается этим профессионально?
K>Когда я по молодости с горящими глазами разбирался с Линуксом, даже техническое описание ext2 вводило в уныние "Да чего так сложно-то??".
Так это же одна из простых ФС, суперблок, карта блоков, карта инодов, и в общем-то все,
примерно тоже самое что UFS из BSD, что именно там сложно?
K>Глупо собирать все эти вещи в одну ФС — должно быть разделение ФС по свойствам. Тогда и загрузка будет не по минуте, а как в БК0010 — ДВЕ секунды от нажатия power!
Так Linux давно грузиться за несколько секунд, точно не за минуту.
Здравствуйте, Михaил, Вы писали:
М>Здравствуйте, igor-booch, Вы писали:
IB>>Неоднократно сталкивался с повреждением файловой системы на Linux разных версий. IB>>Иногда удавалось восстановить иногда нет. IB>>Бывало после отключения электричества, бывало не с того не с сего. IB>>На Windows таких проблем меньше. IB>>Насколько устойчива и защищена файловая система Linux по сравнению с Windows?
М>По моим наблюдениям, как минимум ext4 не предназначена для резкого отключения питания — как минимум, пропадают файлы, как максимум root fs вообще не монтируется, и получается boot loop (причем встроенный fsck по какой то причине (не разбирался по какой) не запускается
Обычно при повреждении файловой системы, в начале загрузки стартует консоль, и из нее можно вызвать fsck. Мне такой вариант помогал с xfs, но с ext4 вообще ошибки бывают очень редко.
Вообще, есть команда sync, которая сбрасывает кеш на диск. После записи больших файлов и перед выключением или крешем, есть смысл sync запускать, тогда повреждений не будет.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, igor-booch, Вы писали:
i> Насколько устойчива и защищена файловая система Linux по сравнению с Windows?
Повреждение "штатной" ext4 (если еще бездумно не копипастить опции монтирования с so) — это одно из последних событий, которое может случиться (т.е. более чем устойчива и надежна).
Здравствуйте, lpd, Вы писали: lpd>Вообще, есть команда sync, которая сбрасывает кеш на диск. После записи больших файлов и перед выключением или крешем, есть смысл sync запускать, тогда повреждений не будет.
Вот это вообще совет на миллион! Главное — перед внезапным выключением или крешем запустить sync.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, lpd, Вы писали: lpd>>Вообще, есть команда sync, которая сбрасывает кеш на диск. После записи больших файлов и перед выключением или крешем, есть смысл sync запускать, тогда повреждений не будет. S>Вот это вообще совет на миллион! Главное — перед внезапным выключением или крешем запустить sync.
"внезапным" это ты добавил. Креш может устроить загрузка недоотлаженного модуля ядра — весьма частая ситуация при разработке драйверов. Так что sync в этом случае помогает.
А если креш внезапный, то журналируемая файловая система метаданные восстановит до рабочего состояния. ext4 по дефолту обычно это молча делает при загрузке.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, Ops, Вы писали:
Z>>С чего-то это вдруг ей портиться в зависимости от количество блоков ждущих записи?
Ops>Невозможно записать 2 разных блока атомарно. Если это блоки с метаданными, то нарушится их целостность.
Ты описываешь баг. Журналируемая ФС не должна портиться при исправной работе устройства хранения в любых ситуациях.
