GJournal и Freebsd 7.2

[LMik]

Единственный вариант когда система не загрузится - ошибки на корневом разделе. Дальше додумайте сами.

Система не загрузится при ошибках на любом разделе, монтируемом автоматически через fstab, если fsck не сможет его проверить.

Система не грузится если корень не clean.

Да, согласен - я не совсем точно сформулировал. В такой постановке вопроса - ты прав. Если корень чист, то ОС загрузится.
Но я переформулирую свою мысль - fsck не смог в background-режиме проверить /usr, /var, /log, или какой нибудь специальный раздел /databases. Базовая система загрузилась, но что толку если полезные сервисы, для работы которых нужны разделы кроме корневого -- не работают? По факту сервер не предоставляет свои функции, он "не работает".
Правильно?

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

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[sch]

В итоге, получили один аргумент в пользу выделения "/" отдельно от других каталогов -- возможность загрузить базовую систему в случае аварии UFS на других разделах.
Забавно, что этот аргумент появляется как следствие ненадежности UFS. То есть, если мы гипотетически представим, что вместо UFS используется другая, устойчивая к авариям питания, файловая система, то необходимости выделять "/" как бы уже нет. Действительно, пахнет линуксом

Какие еще могут быть доводы для разделения ФС?

[snorlov]

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

[LMik]

В итоге, получили один аргумент в пользу выделения "/" отдельно от других каталогов -- возможность загрузить базовую систему в случае аварии UFS на других разделах.
Забавно, что этот аргумент появляется как следствие ненадежности UFS. То есть, если мы гипотетически представим, что вместо UFS используется другая, устойчивая к авариям питания, файловая система, то необходимости выделять "/" как бы уже нет. Действительно, пахнет линуксом

Какие еще могут быть доводы для разделения ФС?

Ещё отдельные разделы /var /tmp не засрут вам всю систему при росте логов или ещё каких либо ситуациях. Я по началу работы с BSD тоже делал один / не понимаю своих ошибок.

[Dorlas]

Все, перезагрузка в нормальный режим. Корневой раздел ранее установленной системы расположен на журналируемом устройстве. Журнал создан на этом же разделе. Вроде все просто, или я не понял проблему?

Отдельно скажу - это не аргумент, что журнал нужен корневому разделу; это доказательство, что в 7.2 можно легко сделать журнал на корневом разделе.

И первая же некорректная перезагрузка такой системы приведет вот к такому:

freebsd

Делал один в один по Вашей инструкции, в первый раз система загрузилась успешно, подмонтировав: /dev/ad0s1a.journala

Вообще, ранее тестировал эту фичу (в декабре 2008), получилось более менее нормально только вот по этой инструкции: http://www.freebsd.org/doc/en_US.ISO885 ... index.html

Для всех разделов пришлось создавать отдельные swap-разделы для журналов, всего было 2 слайса и штук 10 разделов...Тестировал устойчивость к перезагрузкам - после 10 перезагрузок ничего не упало (делал и dd, и порты ставил)...НО линейная скорость записи на диск упала примерно в 3 раза...Скорость чтения вроде тоже (цифер не помню). Поэтому пришлось на тот момент от GJournal отказаться.

[sch]

И первая же некорректная перезагрузка такой системы приведет вот к такому:

ну да, gjournal не очень надежен, я с этим согласен.

Для всех разделов пришлось создавать отдельные swap-разделы для журналов, всего было 2 слайса и штук 10 разделов...Тестировал устойчивость к перезагрузкам - после 10 перезагрузок ничего не упало (делал и dd, и порты ставил)...НО линейная скорость записи на диск упала примерно в 3 раза...Скорость чтения вроде тоже (цифер не помню). Поэтому пришлось на тот момент от GJournal отказаться.

И про скорость согласен, увы.

[sch]

В итоге, получили один аргумент в пользу выделения "/" отдельно от других каталогов -- возможность загрузить базовую систему в случае аварии UFS на других разделах.
Забавно, что этот аргумент появляется как следствие ненадежности UFS. То есть, если мы гипотетически представим, что вместо UFS используется другая, устойчивая к авариям питания, файловая система, то необходимости выделять "/" как бы уже нет. Действительно, пахнет линуксом

Какие еще могут быть доводы для разделения ФС?

Ещё отдельные разделы /var /tmp не засрут вам всю систему при росте логов или ещё каких либо ситуациях. Я по началу работы с BSD тоже делал один / не понимаю своих ошибок.

Я ждал этот аргумент в первую очередь
IMHO, активное использование отдельных партиций для разных частей ФС потеряло актуальность с уходом из продажи маленьких дисков. Основной мотив для использования этой схемы (как мне кажется) был в том, что диск на 20МБ как бы маловат под многие задачи даже того времени. Ну а сегодня-то, такой проблемы нет.
Поэтому:
не будет ли более правильным настроить newsyslog в соответствии с возможными сценариями роста журнала - паковать каждые 10 мегабайт например.
Я имею в виду, что по моему убеждению, гораздо лучше для администратора будет разобраться как работают сервисы в системе, и заранее спланировать возможные проблемы с журналами, а не тупо выделять 10ГБ на журналы, а дальше пофиг - "я сделал как в книжке написали". А переполнится раздел с журналами - и что? Такая ситуация очень даже не всегда является маловажной.
Следить за заполненностью разделов все равно надо, независимо от того, отдельный раздел для журналов или нет. И опять таки, мы живем сегодня, а не в 90-х годах: винчестер на 320ГБ достаточно дешевый и слишком большой, для того чтобы его заполнили журналы за такое короткое время, что администратор и понять не успел. Повторюсь - следить за свободным местом на разделах надо все равно - есть у тебя отдельный раздел для журналов или нет.
Про tmp вообще говорить не буду. Безопаснее не выделять его вообще на большом диске, чем ограничивать какими-нибудь 20ГБ. Потому что 20ГБ может и не хватить для какой-то разовой задачи, а на общем разделе большого диска запас места побольше. Я исхожу из того, что в tmp в процессе работы фоновых сервисов ничего активно не пишется; этот каталог обычно нужен при выполнении ручных административных работ. А если почистить за собой - то и место освободится.

Так что на сегодняшний день действительно проблемой для одного большого раздела является долгая работа fsck в случае аварии питания. Вроде так.

[ev]

Так что на сегодняшний день действительно проблемой для одного большого раздела является долгая работа fsck в случае аварии питания. Вроде так.

еще установка квот, назначение разделов рид-онли, использование различных ФС, журналирование ФС и т.п.
вот и получается - разбивка диска еще долго будет актуальна

[sch]

Так что на сегодняшний день действительно проблемой для одного большого раздела является долгая работа fsck в случае аварии питания. Вроде так.

еще установка квот, назначение разделов рид-онли, использование различных ФС, журналирование ФС и т.п.
вот и получается - разбивка диска еще долго будет актуальна

- чем тебе помешает включение квот на общем разделе?
- read-only для корневого раздела наверное аргумент. Надо подумать
- какие такие разные ФС ты будешь использовать для tmp, log, var? ZFS дает эффект на дисковых массивах, и это уже слабо относится к теме выделения / от других служебных каталогов системы
- журналирование имеет смысл, если журнал создавать на отдельном физическом диске, а не на разделе винчестера, где система установлена

[Dorlas]

- журналирование имеет смысл, если журнал создавать на отдельном физическом диске, а не на разделе винчестера, где система установлена

Оно имеет смысл в ситуации, когда есть несколько разделов обычного объема (10-20 Гб) и некий большой раздел /data (гигов на 500-800) с данными, которые меняются редко и в основном раздаются (FTP,RSYNC, HTTP) - в этом случае я бы на /data журнал навесил, чтобы его не чекать

[sch]

- журналирование имеет смысл, если журнал создавать на отдельном физическом диске, а не на разделе винчестера, где система установлена

Оно имеет смысл в ситуации, когда есть несколько разделов обычного объема (10-20 Гб) и некий большой раздел /data (гигов на 500-800) с данными, которые меняются редко и в основном раздаются (FTP,RSYNC, HTTP) - в этом случае я бы на /data журнал навесил, чтобы его не чекать

так мы об одном и том же говорим

[ev]

чем тебе помешает включение квот на общем разделе?

уменьшение производительности

read-only для корневого раздела наверное аргумент

не только корневого
можно установить набор софта и зафиксировать его

[rambomax]

Прошла неделя - я победил gmirror gjournal и Freebsd 7.2
Проблема оказалась не в Freebsd 7.2, а в винтах WD 500 Гб. Оказалось, что журнал может создаваться только на слайсах, не заходящих за какую-то цифру блоков. Я не стал разбираться, и сделал три зеркальных журналируемых раздела внутри 300Гб, а остальное пространство выкинул под мусор.
В итоге всё работает ОК.
Делал ресеты, выдёргивал шнур питания - живёт всё равно. Зеркало не разваливается.
Это к вопросу надо ли разбивать винт. В моём случае попытка сделать один слайс на весь диск и прикрутить к нему журнал была фатальной - железо развивается быстрее софта.

[Alex Keda]

а я в рассылке видел рекомендацию

Код: Выделить всё

2 2

ставить...

[Dorlas]

Прошла неделя - я победил gmirror gjournal и Freebsd 7.2
Проблема оказалась не в Freebsd 7.2, а в винтах WD 500 Гб. Оказалось, что журнал может создаваться только на слайсах, не заходящих за какую-то цифру блоков. Я не стал разбираться, и сделал три зеркальных журналируемых раздела внутри 300Гб, а остальное пространство выкинул под мусор.
В итоге всё работает ОК.
Делал ресеты, выдёргивал шнур питания - живёт всё равно. Зеркало не разваливается.
Это к вопросу надо ли разбивать винт. В моём случае попытка сделать один слайс на весь диск и прикрутить к нему журнал была фатальной - железо развивается быстрее софта.

Две недели назад построил сервер на FreeBSD 7.2-STABLE (AMD64) - использовал ZFS v13. Как только ни старался получить kernel panic, не получилось! (dd, bonnie++, dbench, много RESET в различных ситуациях - сборка ядра, портов, работа служб, запись в MySQL) - ну работает и все тут. И zpool scrub tank ошибок не показывает (что логично, учитывая архитектуру ZFS).

Так что я про fsck просто забыл. Да и пользоваться ZFS в ряде случаев удобнее намного, файловые системы под задачи создавать. Ну и быстродействие конечно - даже на глаз разница при копировании видна.

[BSDNoob]

На UFS2 журнал не нужен. Его код написали по принципу "чтобы было" и чтобы линупсоеды пальцем не показывали.

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

Почему нельзя выполнять fsck в фоне? Ведь при использовании soft updates с вероятностью близкой к 100% можно сказать, что ФС не была повреждена.

[dvg_lab]

делаю новый сервер, тоже решил заморочится с gjournal ведь в хэндбуке все так просто три команды и вуа-ля, только вот как результат, я думаю что я больше никогда не буду использовать gjournal на продакшене.
Система 7.2Release amd64, массивы на adaptec 2230S, три штуки, после некоторого количества экспериментов с gjournal label, gjournal stop и gjournal clear эта сволочь начинает ругаться на operation not permitted, и _никакими_ средсвами от этой ошибки избавиться нельзя и также невозможно заюзать опять этот раздел, мне пришлось поновой переразбивать диск ставить все с нуля. Причем я не представляю что я буду делать если во врмемя боевого дежурства сервера вдруг вылетит зеркало с журналами, а все команды мне будут говорить что operation not permitted. Трахаюсь уже два дня, весь гугл перерыл, все возможные sysctl перепробовал, а оно хоть ты тресни not permitted. Короче gjournal ацтой. Причем сейчас ситуация такая что даже в сингл юзер моде не грузится, ждет монтирования подсистемы gjournal, а она не может подмонтировать не корневой /home раздел, и вываливается опять в waitng for mount и так в цикле пока резет не нажмешь.
Насколько смог понять после прочтения гугла, проблема может быть в том что данные и журнал на разных SCSI винтах, опция GEOM_JOURNAL вкомпилена в ядро, и как здесь писали что-то связано с размерами слайсов. Вообще не понятно как можно было запихивать глючный функционал в релиз. Пожалуй второй раз за 4 года я не в восторге от фри. Первый раз был неделю назад, в портах лежат протухшие isc-dhcpd версии сервера. Причем один порт который официально тыщу лет как end of life (3.0.7), а второй вообще BROKEN потому что (NOT YET INTEGRATED) и в джайле не пашет.

Если хотите повторить эксперимент отберите у gjournal раздел с журналом через gjournal clear <journal_provider> и попытайтесь потом вернуть диск из журналируемого в обычный вид.

[iZEN]

Может всё таки диски сыпятся, а не gjournal виноват?

[dvg_lab]

Может всё таки диски сыпятся, а не gjournal виноват?

если бы... это же ведь рейды, два 10 и один просто зеркало, ты всетаки поэкспериментируй с gjournal, очень неоднозначная система, меня больше всего бесит в этом то что нельзя все удалить, нельзя взять и затереть этот последний сектор на слайсе. Блин fsck на разделе проходит, а примонтировать его ни в ro никак вообще нельзя. Имхо они с этой защитой последнего сектора намудрили. Обязательно нужно было оставить возможность обнулить его.
Еще прикол, заходишь с сисинсталл сносишь этот раздел aacd01sf в частности, перегружаешься, все нормально, проблем нет, geom молчит, но как только опять размечаешь этот раздел и перегружаешься, все трындец, опять начинается нытье gjournal что у него timeout и на все запросы опять operation not permitted, имхо реально этот код написан по типу лиж бы было. Я не знаю, может какой-то отдельный раздел типа некислого размера с хранением журнала в нем же и спасет ситуацию, но мне не понравилось это. Как это так отвалился раздел с журналом, все fdisk и bsdlabel вам в руки, я еще конечно в виртуалке покручу, но в прокдакшен однозначно нет.

[Alex Keda]

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

Код: Выделить всё

man dd

?
==============
а я почти всё своё на него перевёл. никак не нарадуюсь ))

[snorlov]

Так и флаг, что это журналируемый раздел, удалил?....

[dvg_lab]

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

Код: Выделить всё

man dd

?
==============
а я почти всё своё на него перевёл. никак не нарадуюсь ))

Лис, скажи пожалуйста какую магическую комбинацию опций применить к dd чтобы затереть _последний_ сектор слайса? А так я все разделы грохнул fdisk`ом, dd мучился бы гораздо дольше . Фишка в том что пока ты именно этот последний сектор не грохнешь geom таки будет его находить.

Что касается удачных внедрений возможно я пошел не правильным путем, во первых 7.2Rel, во вторых amd64, в третьих отдельный рейд под журналы, массив 140гиг, поделил на 6 кусков, aacd2s1{a,d,e,f,g,h} вот их и лепил к соотв. aacd0s1 разделам. Ну я не знаю что еще можно было изобрести чтоб снять метки, загрузка с ливцд также не помогала, те же нот пермиттед, хоть ты застрелись. Я все же поэкспериментирую как время появится, на ноуте по любому запаривает ждать пока /home прочекается, но на ноуте HEAD, возможно там и получится.

Почитал про gated & gmirror, понял что там тоже куча костылей. Сегодня целый день докручивал тоже самое только с использованием gamin и ssh. Получилось тоже самое только без гимора, мне нужно было при измнении файла зеркалить его на слейв сервак, то есть по событию, а не по крону. Тоже конечно костыль, но он меня целиком устраивает, получился неплохой кластер из isc-dhcpd серверов.

[Alex Keda]

Код: Выделить всё

hosting# bsdlabel /dev/mirror/gm0s1
# /dev/mirror/gm0s1:
8 partitions:
#        size   offset    fstype   [fsize bsize bps/cpg]
  a:  1048576        0    4.2BSD     2048 16384     8
  b:  8388608  1048576      swap
  c: 312576642        0    unused        0     0         # "raw" part, don't edit
  d: 16777216  9437184    4.2BSD     2048 16384 28528
  e: 33554432 26214400    4.2BSD     2048 16384 28528
  f: 252807810 59768832    4.2BSD     2048 16384 28528
hosting#    

помоему, последний сектор посчитать не так сложно, если подумать?
==========
а вот журнал я всегда встроенный делаю, а не на отдельных дисках/разделах.
у меня тока один не встроенный - на рабочей машине.
просто так получилось.

[dvg_lab]

помоему, последний сектор посчитать не так сложно, если подумать?

издеваешься? посчитал я допустим последний сектор, дальше что делать? любимый dd в последний сектор как направить? Не спорю что есть возможно и disk editor некий под фрю, но времени ковырять порты честно не было, мне надо чтоб сервак кровь из носа к концу недели встал на боевое дежурство, а учитывая сколько я в него собираюсь вареза напихать, да еще и желательно отдельные сервисы продублировать в failover... вобщем не до экспериментов, это просто моя тяга все и везде улучшить, сделать совсем красиво

Кстати все кто внедрял у себя failover на фре, приглашаю к обмену мнениями. Сейчас копаю инфу по файловеру для postfix (релей), squid и bind. Но интересно обсудить любые сервисы в failover режиме.

а вот журнал я всегда встроенный делаю, а не на отдельных дисках/разделах.
у меня тока один не встроенный - на рабочей машине.
просто так получилось.

ну вот видимо тут кроется причина моих неудач, но опять же да, я согласен, я в первый раз завёл журнал, он завелся, все зашибись, (только почему-то пришлось перегружаться, иначе провайдер .journal в /dev не появился) потом я решил опять же по инструкции разобрать этот gjournal, ну чтоб проверить что делать в ситуации ЧП там я не знаю, всякое бывает. И вот разобрать я его уже не смог. Получилось только снять метку с раздела с журналом, но после этого он вообще впал в ступор и единственный выход был fdisk.

Кстати почему-то разнятся данные о скорости, нашел две противоположные точки зрения, кто-то говорит что с журналом гораздо тормознее (20%) а кто-то говорит что с журналом да на отдельном диске еще и с async вообще быстрее чем soft updates. Может быть разные версии фри? Хотя посмотрел код gjournal его уже 2 года не трогают.

[Alex Keda]

помоему, последний сектор посчитать не так сложно, если подумать?

издеваешься? посчитал я допустим последний сектор, дальше что делать? любимый dd в последний сектор как направить?

мда...

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

Код: Выделить всё

man dd

?

ниасилил?

Код: Выделить всё

     skip=n   Skip n blocks from the beginning of the input before copying.
              On input which supports seeks, an lseek(2) operation is used.
              Otherwise, input data is read and discarded.  For pipes, the
              correct number of bytes is read.  For all other devices, the
              correct number of blocks is read without distinguishing between
              a partial or complete block being read.

но это медленно. секами/осеками быстрей на порядки будет