![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
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.
no subject
Date: 2011-09-05 14:11 (UTC)к сожалению, любая fs с алгоритмом сложнее async -- слишком сложная вещь требующая слишком длительной отладки. даже для ufs потребовалось больше 10 лет отладки
no subject
Date: 2011-09-05 15:12 (UTC)no subject
Date: 2011-09-05 15:53 (UTC)no subject
Date: 2011-09-05 17:02 (UTC)кто ее тестировал в условиях нехватки ресурсов? нагрузки? внезапных крэшей? пропадания питания?
у меня разваливалась fs от не менее именитой конторый
no subject
Date: 2011-09-05 17:38 (UTC)Например, Fish Labs, когда делали Thumper. Если это тебе что-то говорит.
Есть ZFS-backed сервера по 48 двухтерабайтных винтов -- я ВИДЕЛ, как их тестировали и сколько это заняло времени. ZFS ОЧЕНЬ живучая. ОЧЕНЬ. За это приходится платить правилом ``пол-гигабайта памяти на терабайт места или будет медленно'' -- Факт. Но УБИТЬ ZFS так, что бы она не поднялась сама, практически невозможно.
no subject
Date: 2011-09-05 17:46 (UTC)нет, мне это ни о чем не говорит.
ну вот она сейчас пошла таки в народ. года через три ясно будет.
у ufs вон, почти двадцать лет не наступали на баг с именем нулевой длины.
no subject
Date: 2011-09-05 17:54 (UTC)Ну а что ты тогда спрашиваешь ``Кто ей тестировал?''? Если тебе ничего не скажут имена людей и названия проектов? Дядя Вася из соседнего подъезда её должен был тестировать?
ну вот она сейчас пошла таки в народ. года через три ясно будет.
Ну, при нынешнем состоянии Соляриса я бы не сказал, что она как-то особо пошла в народ. Про FreeBSD, Увы, даже говорить смешно, причём в двух смыслах -- и аудитория FreeBSD и то, что там всё же порт, а ZFS не UFS -- так просто не отторгается от OS, увы, так как использует всё до предела.
Впрочем, глядя на продажи storage-Серверов от Sun, я бы сказал, что пошла в народ она давно. Просто этого не очень видно в России -- да и вообще не очень видно, так как эти сервера -- коробки с Web-интерфейсом и ZFS там или FuckFS клиент вообще не знает и знать не должен.
С третье стороны, хочу сказать, что UFS даже в версии FFS2+SU мало пригодная в современных условиях штука: fsck на приличном томе даже не в фоне идёт у меня дома больше 40 минут, в фоне -- больше двух часов (причём, больше часа из этого FS прветически мертва и обращение к ней вешает программы на десятки минут), бэкап без остановки сервера не сделать (так как создание снепшота занимает больше 2 часов, морозит сервер и всё равно обламывается в 2 из 3 случаев), etc. И это всё было на 2Tb. Сейчас у меня этих терабайт восемь и я в ужасе.
no subject
Date: 2011-09-05 17:59 (UTC)no subject
Date: 2011-09-05 18:05 (UTC)Жду-не-дождусь. Это не ирония, это факт, проапгрейжуcь на 9-RELEASE сразу как выйдет и рискну включить эту штуку. Вот только, боюсь,
И это не решает проблему бэкапа.
UFS2+ASYNC+GJOURNAL
Я тестировал. Скорость линейной записи падает почти вдвое, если нет денег на SSD под журнал. Меня это категорически не устраивало.
no subject
Date: 2011-09-05 18:30 (UTC)От задач зависит. У меня, наоборот, было ускорение более чем в 2.5 раза на куче мелких записей - на развертывании дерева портов на пустую fs в случае softupdates и в случае async+gjournal.
no subject
Date: 2011-09-05 18:52 (UTC)no subject
Date: 2011-09-05 19:00 (UTC)(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2011-09-05 18:50 (UTC)еще и генетика плохая
no subject
Date: 2011-09-05 18:47 (UTC)это риторический вопрос. я поверю только в тестирование реальной эксплуатация в говеных условиях в течении лет 10. ну хотя бы 5.
что бы без упсов, с выжиранием места и отваливанием линка до hdd
ну правильно выбираем количество инод, размер фрагмента и fsck резко ускоряется.
и по мне так лучше fsck на 40 минут, чем покрошенная в спагети fs и востанавление ее в течении недели ручками и перловым скриптом.
no subject
Date: 2011-09-05 18:54 (UTC)Да? У меня число инод было умолчательным, а вот размер блока -- 64 килобайта и фрагмента, соответственно, 8 килобайт. Больше некуда.
no subject
Date: 2011-09-05 19:02 (UTC)no subject
Date: 2011-09-05 19:28 (UTC)И вот, кстати о. Полная ненастраиваемость живой UFS2 (в смысле, без newfs) -- это тоже регулярно неудобно. growfs сделали и на том спасибо...
(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2011-09-05 20:26 (UTC)no subject
Date: 2011-09-05 17:55 (UTC)Ужасный, страшный баг, разрушающий тома в хлам, да. По мне, так это несущественная косметика. А вот то, что бэкап не сделать на лету надёжный -- шоустоппер для многих применений.
no subject
Date: 2011-09-05 18:02 (UTC)Бекап делается мгновенно при помощи gmirror - из зеркала выводится один из дисков, по нему прогоняется fsck и потом он либо уносится для оффлайнового бекапа, либо с него спокойно снимается дамп online. Потом диск возвращается в gmirror и обратно сихронизируется.
no subject
Date: 2011-09-05 18:12 (UTC)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 не париться...
no subject
Date: 2011-09-05 18:41 (UTC)Странные ошибки во время работы чуть более сложного приложения на "чистой" файловой системе могли так просто не разрешаться. Представим, что в каталоге за этой поврежденной записью ещё файлы/каталоги с нужными данными записаны в следующих записях :-)
> второй винт ``вынут'' из зеркала, и потери данных изрядные.
Почему второй? Третий.
> автоматизация всех этих выниманий-вставляний зеркала -- это уже сложнее
Я тебя не понимаю, что может быть сложного в одной команде gmirror remove? Или в gmirror insert. Даже gmirror rebuild не надо потом говорить, оно само.
> Синхронизация всего зеркала на больших дисках -- это часы опять же, во время которых производительность FS так себе.
Нормальная там производительность, лучше чем при снятии дампа с устройств в работе.
> В конечном итоге, это требует зеркала!
А бекап сливается в пустоту что ли? :-) Зеркало это хорошо.
> ну да, тогда можно уже RAID10 собрать, и с RAID5 не париться
И я про то же :-) На самом деле, gmirror всё равно, чем у него являются провайдеры. Он может отзеркалировать и RAID5 на geom_gate по сети.
no subject
Date: 2011-09-05 18:51 (UTC)Оуч. Это уже в случае Dedicated СОВСЕМ другие деньги. 2 винта сейчас -- норма. 3 -- уже доп-опция, везде недешёвая.
Я тебя не понимаю, что может быть сложного в одной команде gmirror remove? Или в gmirror insert.
Убедится, что оно выполнилось и сделало то, что нужно? ;-)
А бекап сливается в пустоту что ли? :-) Зеркало это хорошо.
Бэкап сливается на бекап-спейс датацентра. Или в какой-нибудь Amazon S3. Зеркало -- это отлично, сам за год уже трижды убедился, но тройное зеркало -- это уже дорого.
\\И я про то же :-) \\
Только вот больше 6 портов SATA хороших в мать получить тоже -- дорого. Ну, у нас тут с тобой разные весовые категории. Меня много лет устраивал dump -L и мне без нго очень плохо на новых объёмах.
(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2011-09-05 16:27 (UTC)no subject
Date: 2011-09-05 17:04 (UTC)Проще, background_fsck="NO". В случае с gjournal всё равно будет быстро.