bgfsck

[dadv]

Пришел к выводу, что background fsck должен быть отключен по умолчанию.

Сегодня удаленный сервер "в чистом поле" (самый квалифицированный из персонала рядом - зоотехник) после длительного отключения питания при загрузке стал циклически перезагружаться (UPS продержался час и умер, не исключены также "подергушки" питания). Помог выход в single user mode и ручной прогон fsck -y при помощи зоотехника, управляемого по телефону (fsck_y_enable="YES" было в /etc/rc.conf). После чего система нормально поднялась. Что странно, так как паник ядра во время background fsck я не видел со времен 6.x. И это несмотря на то, что машина работает на двух дисках с gmirror+gjournal, то есть проверять-то fsck ничего и не надо было... Отключил background_fsck в /etc/rc.conf

Задумался о создании /etc/rc.d/upscheck, который бы стартовал после активации свопа, но перед первым запуском fsck и при помощи статически слинкованного /root/bin/apctest проверял уровень зарядки аккумуляторов UPS и приостанавливал загрузку, если заряд критически низкий и очередной сбой питания может прервать загрузку, включая выполнение journal rollback и foreground fsck.

Comments

[http://users.livejournal.com/_slw/]

я это говорю еще с начала 2000-х

к сожалению, любая fs с алгоритмом сложнее async -- слишком сложная вещь требующая слишком длительной отладки. даже для ufs потребовалось больше 10 лет отладки

[blacklion.livejournal.com]

ZFS запилили в оригинале быстрее и в оригинале серьёзных претензий я к ней не видел уже года два как.

[frotmnenogi.livejournal.com]

ага

[http://users.livejournal.com/_slw/]

прости, я не верю в эти сказки.
кто ее тестировал в условиях нехватки ресурсов? нагрузки? внезапных крэшей? пропадания питания?

у меня разваливалась fs от не менее именитой конторый

[blacklion.livejournal.com]

кто ее тестировал в условиях нехватки ресурсов? нагрузки? внезапных крэшей? пропадания питания?
Например, Fish Labs, когда делали Thumper. Если это тебе что-то говорит.

Есть ZFS-backed сервера по 48 двухтерабайтных винтов -- я ВИДЕЛ, как их тестировали и сколько это заняло времени. ZFS ОЧЕНЬ живучая. ОЧЕНЬ. За это приходится платить правилом ``пол-гигабайта памяти на терабайт места или будет медленно'' -- Факт. Но УБИТЬ ZFS так, что бы она не поднялась сама, практически невозможно.

[http://users.livejournal.com/_slw/]

Например, Fish Labs, когда делали Thumper. Если это тебе что-то говорит.

нет, мне это ни о чем не говорит.

Есть ZFS-backed сервера по 48 двухтерабайтных винтов -- я ВИДЕЛ, как их тестировали и сколько это заняло времени. ZFS ОЧЕНЬ живучая. ОЧЕНЬ. За это приходится платить правилом ``пол-гигабайта памяти на терабайт места или будет медленно'' -- Факт. Но УБИТЬ ZFS так, что бы она не поднялась сама, практически невозможно.

ну вот она сейчас пошла таки в народ. года через три ясно будет.
у ufs вон, почти двадцать лет не наступали на баг с именем нулевой длины.

[blacklion.livejournal.com]

нет, мне это ни о чем не говорит.
Ну а что ты тогда спрашиваешь ``Кто ей тестировал?''? Если тебе ничего не скажут имена людей и названия проектов? Дядя Вася из соседнего подъезда её должен был тестировать?

ну вот она сейчас пошла таки в народ. года через три ясно будет.
Ну, при нынешнем состоянии Соляриса я бы не сказал, что она как-то особо пошла в народ. Про FreeBSD, Увы, даже говорить смешно, причём в двух смыслах -- и аудитория FreeBSD и то, что там всё же порт, а ZFS не UFS -- так просто не отторгается от OS, увы, так как использует всё до предела.

Впрочем, глядя на продажи storage-Серверов от Sun, я бы сказал, что пошла в народ она давно. Просто этого не очень видно в России -- да и вообще не очень видно, так как эти сервера -- коробки с Web-интерфейсом и ZFS там или FuckFS клиент вообще не знает и знать не должен.

С третье стороны, хочу сказать, что UFS даже в версии FFS2+SU мало пригодная в современных условиях штука: fsck на приличном томе даже не в фоне идёт у меня дома больше 40 минут, в фоне -- больше двух часов (причём, больше часа из этого FS прветически мертва и обращение к ней вешает программы на десятки минут), бэкап без остановки сервера не сделать (так как создание снепшота занимает больше 2 часов, морозит сервер и всё равно обламывается в 2 из 3 случаев), etc. И это всё было на 2Tb. Сейчас у меня этих терабайт восемь и я в ужасе.

[dadv.livejournal.com]

UFS2+SU+J, UFS2+ASYNC+GJOURNAL - выбирай на вкус.

[blacklion.livejournal.com]

UFS2+SU+J
Жду-не-дождусь. Это не ирония, это факт, проапгрейжуcь на 9-RELEASE сразу как выйдет и рискну включить эту штуку. Вот только, боюсь, _slw верить этому так же не будет -- ему лет заметно меньше чем ZFS, userbase меньше.
И это не решает проблему бэкапа.

UFS2+ASYNC+GJOURNAL
Я тестировал. Скорость линейной записи падает почти вдвое, если нет денег на SSD под журнал. Меня это категорически не устраивало.

[dadv.livejournal.com]

> Скорость линейной записи падает почти вдвое, если нет денег на SSD под журнал. Меня это категорически не устраивало.

От задач зависит. У меня, наоборот, было ускорение более чем в 2.5 раза на куче мелких записей - на развертывании дерева портов на пустую fs в случае softupdates и в случае async+gjournal.

[blacklion.livejournal.com]

Ну, я потому и не пишу, что это вообще негодное решение -- но на моих домашних задачах оно портит всю малину.

[dadv.livejournal.com]

А я дома на нём живу и не жужжу :-) Что за задачи-то у тебя такие?

[http://users.livejournal.com/_slw/]

UFS2+SU+J
Жду-не-дождусь. Это не ирония, это факт, проапгрейжуcь на 9-RELEASE сразу как выйдет и рискну включить эту штуку. Вот только, боюсь, [info]_slw верить этому так же не будет -- ему лет заметно меньше чем ZFS, userbase меньше.

еще и генетика плохая

[http://users.livejournal.com/_slw/]

Ну а что ты тогда спрашиваешь ``Кто ей тестировал?''? Если тебе ничего не скажут имена людей и названия проектов? Дядя Вася из соседнего подъезда её должен был тестировать?

это риторический вопрос. я поверю только в тестирование реальной эксплуатация в говеных условиях в течении лет 10. ну хотя бы 5.
что бы без упсов, с выжиранием места и отваливанием линка до hdd

С третье стороны, хочу сказать, что UFS даже в версии FFS2+SU мало пригодная в современных условиях штука: fsck на приличном томе даже не в фоне идёт у меня дома больше 40 минут, в фоне -- больше двух часов (причём, больше часа из этого FS прветически мертва и обращение к ней вешает программы на десятки минут), бэкап без остановки сервера не сделать (так как создание снепшота занимает больше 2 часов, морозит сервер и всё равно обламывается в 2 из 3 случаев), etc. И это всё было на 2Tb. Сейчас у меня этих терабайт восемь и я в ужасе.

ну правильно выбираем количество инод, размер фрагмента и fsck резко ускоряется.

и по мне так лучше fsck на 40 минут, чем покрошенная в спагети fs и востанавление ее в течении недели ручками и перловым скриптом.

[blacklion.livejournal.com]

ну правильно выбираем количество инод, размер фрагмента и fsck резко ускоряется.
Да? У меня число инод было умолчательным, а вот размер блока -- 64 килобайта и фрагмента, соответственно, 8 килобайт. Больше некуда.

[dadv.livejournal.com]

Имеется в виду newfs -i (про него и в man tuning есть).

[blacklion.livejournal.com]

Это я понимаю, что newfs -i. Я про то, что его я не трогал.

И вот, кстати о. Полная ненастраиваемость живой UFS2 (в смысле, без newfs) -- это тоже регулярно неудобно. growfs сделали и на том спасибо...

[http://users.livejournal.com/_slw/]

умолчательное число инод черезчур велико в большинстве случаев.

[blacklion.livejournal.com]

у ufs вон, почти двадцать лет не наступали на баг с именем нулевой длины.
Ужасный, страшный баг, разрушающий тома в хлам, да. По мне, так это несущественная косметика. А вот то, что бэкап не сделать на лету надёжный -- шоустоппер для многих применений.

[dadv.livejournal.com]

Эта несущественная косметика стала для меня шоустоппером, потому что тупо нельзя было почистить obj - такой каталог не удалялся.

Бекап делается мгновенно при помощи gmirror - из зеркала выводится один из дисков, по нему прогоняется fsck и потом он либо уносится для оффлайнового бекапа, либо с него спокойно снимается дамп online. Потом диск возвращается в gmirror и обратно сихронизируется.

[blacklion.livejournal.com]

нельзя было почистить obj - такой каталог не удалялся.
mv /usr/obj /usr/grabage.to.fix.later и всё.

Про gmirror -- это плохо, очень плохо. Т.е. это адский паллиатив, я уж лучше запакую всё star'ом и чёрт с ними, с инконсистенси.

Мои претензии к этому методу:

(1) Незащищённость пока бэкап. Если бэкап льётся по сети -- это может быть долго в момент level0, вплоть до ЧАСОВ. Если в этот момент накрылся основнй винт -- всё грустно и само не грузится, так как второй винт ``вынут'' из зеркала, и потери данных изрядные.

(2) Плохо автоматизируется. Обёртка вокруг dump требует мало, автоматизация всех этих выниманий-вставляний зеркала -- это уже сложнее, особенно учитывая, какой немашинопарсабелтный вид у вывода geom-тулов (это соседняя проблема, конечно)

(3) Синхронизация всего зеркала на больших дисках -- это часы опять же, во время которых производительность FS так себе.

(4) В конечном итоге, это требует зеркала! :) Что не всегда возможно и/или оправданно финансово (да, HDD стоит дёшево -- а вот аренда сервера с 1 или 2 дисками может отличатся в месяц уже существенно).

(5) Если у меня RAID5, скажем, -- мне удваивать все 5 винтов, ставить 10? ну да, тогда можно уже RAID10 собрать, и с RAID5 не париться...

[dadv.livejournal.com]

> mv /usr/obj /usr/grabage.to.fix.later и всё.

Странные ошибки во время работы чуть более сложного приложения на "чистой" файловой системе могли так просто не разрешаться. Представим, что в каталоге за этой поврежденной записью ещё файлы/каталоги с нужными данными записаны в следующих записях :-)

> второй винт ``вынут'' из зеркала, и потери данных изрядные.

Почему второй? Третий.

> автоматизация всех этих выниманий-вставляний зеркала -- это уже сложнее

Я тебя не понимаю, что может быть сложного в одной команде gmirror remove? Или в gmirror insert. Даже gmirror rebuild не надо потом говорить, оно само.

> Синхронизация всего зеркала на больших дисках -- это часы опять же, во время которых производительность FS так себе.

Нормальная там производительность, лучше чем при снятии дампа с устройств в работе.

> В конечном итоге, это требует зеркала!

А бекап сливается в пустоту что ли? :-) Зеркало это хорошо.

> ну да, тогда можно уже RAID10 собрать, и с RAID5 не париться

И я про то же :-) На самом деле, gmirror всё равно, чем у него являются провайдеры. Он может отзеркалировать и RAID5 на geom_gate по сети.

[blacklion.livejournal.com]

Почему второй? Третий.
Оуч. Это уже в случае Dedicated СОВСЕМ другие деньги. 2 винта сейчас -- норма. 3 -- уже доп-опция, везде недешёвая.

Я тебя не понимаю, что может быть сложного в одной команде gmirror remove? Или в gmirror insert.
Убедится, что оно выполнилось и сделало то, что нужно? ;-)

А бекап сливается в пустоту что ли? :-) Зеркало это хорошо.
Бэкап сливается на бекап-спейс датацентра. Или в какой-нибудь Amazon S3. Зеркало -- это отлично, сам за год уже трижды убедился, но тройное зеркало -- это уже дорого.

\\И я про то же :-) \\
Только вот больше 6 портов SATA хороших в мать получить тоже -- дорого. Ну, у нас тут с тобой разные весовые категории. Меня много лет устраивал dump -L и мне без нго очень плохо на новых объёмах.

[tarkhil.livejournal.com]

zfs? И установить УПСу более ранний отбой?

[dadv.livejournal.com]

> zfs?

Проще, background_fsck="NO". В случае с gjournal всё равно будет быстро.