Исходное сообщение
"Изучение изменения размера кодовой базы Ext4, Btrfs и XFS" Отправлено iZEN, 25-Июн-11 20:58
>> Ну есть zdb если на то уж пошло. > Он может проверить все структуры на валидность и починить все что невалидно > или хотя-бы нейтрализовать, чтобы пул можно было смонтировать и выколупать то > что уцелело? http://www.freebsd.org/cgi/man.cgi?query=zdb >> блоки-потеряшки, здесь в случае сбоя ZFS откатится на предыдущее состояние лога. > А теперь представьте себе что цепочка логов порушилась где-то в середине. Или > метаданные описываюшие оную. То только эта цепочка и будет недоступна. >> Во время же выделения мы проигрываем лог. > Вы рассматриваете только простые сбои, которые должна обработать обычная логика журналирования. > Тогда как fsck обычно пользуются лишь тогда, когда эта логика не > смогла отработать как надо. В самом деле? https://osu.redhat.com/content/courses-ru/rha130-50-2-ru/tag... --- Использование команды fsck Команда fsck обычно вызывается с именем раздела, который нужно проверить, в качестве единственного параметра. Если команда fsck найдет ошибку, которую она сможет исправить без риска потери данных, она исправит ее. Если есть риск потери данных, команда fsck приостановится и выдаст сообщение с вопросом, должна ли она исправлять ошибку. Для администраторов, которые не обладают подробными знаниями в области внутренней структуры файловой системы ext2, выбор невелик. По правде говоря, команда fsck часто запускается с ключом -y, который так и говорит: "Не спрашивать, просто делать". --- > Когда мы видим что дело дрянь и основной парашют не сработал - нервно сглатываем и дергаем запасной. А он у вас есть? Бэкапы хотя бы сделали? :)) > А вы в вашем праве превращаться в лепешку, если вам так удобнее. У нас хотя бы мусор из-за бэд-блока на одном носителе можно достоверно обнаружить, а на группе носителей в RAID невозможен в принципе.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>>> Ну есть zdb если на то уж пошло. >> Он может проверить все структуры на валидность и починить все что невалидно >> или хотя-бы нейтрализовать, чтобы пул можно было смонтировать и выколупать то >> что уцелело? > http://www.freebsd.org/cgi/man.cgi?query=zdb >>> блоки-потеряшки, здесь в случае сбоя ZFS откатится на предыдущее состояние лога. >> А теперь представьте себе что цепочка логов порушилась где-то в середине. Или >> метаданные описываюшие оную. > То только эта цепочка и будет недоступна. >>> Во время же выделения мы проигрываем лог. >> Вы рассматриваете только простые сбои, которые должна обработать обычная логика журналирования. >> Тогда как fsck обычно пользуются лишь тогда, когда эта логика не >> смогла отработать как надо. > В самом деле? > https://osu.redhat.com/content/courses-ru/rha130-50-2-ru/tag_filesystems/tag_lessons/tag_fscmds/tag_discussion/tag_fsck/section_0001 > --- > Использование команды fsck > Команда fsck обычно вызывается с именем раздела, который нужно проверить, в качестве > единственного параметра. Если команда fsck найдет ошибку, которую она сможет исправить > без риска потери данных, она исправит ее. Если есть риск потери > данных, команда fsck приостановится и выдаст сообщение с вопросом, должна ли > она исправлять ошибку. Для администраторов, которые не обладают подробными знаниями в > области внутренней структуры файловой системы ext2, выбор невелик. По правде говоря, > команда fsck часто запускается с ключом -y, который так и говорит: > "Не спрашивать, просто делать". > --- >> Когда мы видим что дело дрянь и основной парашют не сработал - нервно сглатываем и дергаем запасной. > А он у вас есть? Бэкапы хотя бы сделали? :)) >> А вы в вашем праве превращаться в лепешку, если вам так удобнее. > У нас хотя бы мусор из-за бэд-блока на одном носителе можно достоверно > обнаружить, а на группе носителей в RAID невозможен в принципе.
	Введите код, изображенный на картинке: