Через кривизни рук сервер під FreeBSD 9,2 RELEASE, будучи під навантаженням, залишився без харчування.
Після завантаження в single-user, і прогону fsck -y НЕ перезавантажився.
Був цейтнот, я толком не запам'ятав, на що він лаявся, щось про named і syslog.
Я далеко не самий холоднокровна людина, і через це самого цейтноту почав здійснювати якісь дурниці.
Знову завантажився в single-user, запустив fsck без -y, відмовився від використання журналу при перевірці, почав тикати "y" на кожне повідомлення fsck, навіть не вчитуючись, але швидко зрозумів, що буду тикати до вечора.
Припинив це справа, знову прогнав fsck -y, і на цей раз сервер завантажився.
З видимих втрат - злетів симлінк / etc / namedb.
Симлінк зробив, запустив named.
Начебто все на місці і працює.
Але внаслідок повної неосвіченості в області файлових систем мучать мене тепер сумніви - а все-ли тепер з цими самими файловими системами в порядку?
Підкажіть, будь ласка, як правильно і остаточно їх перевірити.
Вони такі:
*** @ kiwi: / usr / home / lx # mount
/ Dev / da0p2 on / (ufs, local, journaled soft-updates)
devfs on / dev (devfs, local, multilabel)
/ Dev / da0p4 on / u (ufs, local, journaled soft-updates)
devfs on / var / named / dev (devfs, l
Post by A***@public.gmane.org
Вітаю!
Через кривизни рук сервер під FreeBSD 9,2 RELEASE, будучи під навантаженням, залишився без харчування.
Після завантаження в single-user, і прогону fsck -y НЕ перезавантажився.
Був цейтнот, я толком не запам'ятав, на що він лаявся, щось про named і syslog.
Я далеко не самий холоднокровна людина, і через це самого цейтноту почав здійснювати якісь дурниці.
Знову завантажився в single-user, запустив fsck без -y, відмовився від використання журналу при перевірці, почав тикати "y" на кожне повідомлення fsck, навіть не вчитуючись, але швидко зрозумів, що> буду тикати до вечора.
Припинив це справа, знову прогнав fsck -y, і на цей раз сервер завантажився.
З видимих втрат - злетів симлінк / etc / namedb.
Симлінк зробив, запустив named.
Начебто все на місці і працює.
Але внаслідок повної неосвіченості в області файлових систем мучать мене тепер сумніви - а все-ли тепер з цими самими файловими системами в порядку?
Підкажіть, будь ласка, як правильно і остаточно їх перевірити.
/ Dev / da0p2 on / (ufs, local, journaled soft-updates)
devfs on / dev (devfs, local, multilabel)
/ Dev / da0p4 on / u (ufs, local, journaled soft-updates)
devfs on / var / named / dev (devfs, local, multilabel)
Напевно занадто тупий питання.
Ну добре, а як народ ставиться до fsck_y_enable = "YES" у rc.conf?
І заодно, що щодо background_fsck = "NO"?
Пишуть, що "YES", який за замовчуванням, може призводити до небажаних последс
Post by A***@public.gmane.org
Вітаю!
Через кривизни рук сервер під FreeBSD 9,2 RELEASE, будучи під навантаженням, залишився без харчування.
Після завантаження в single-user, і прогону fsck -y НЕ перезавантажився.
Був цейтнот, я толком не запам'ятав, на що він лаявся, щось про named і syslog.
Я далеко не самий холоднокровна людина, і через це самого цейтноту почав здійснювати якісь дурниці.
Знову завантажився в single-user, запустив fsck без -y, відмовився від використання журналу при перевірці, почав тикати "y" на кожне повідомлення fsck, навіть не вчитуючись, але швидко зрозумів, що> буду тикати до вечора.
Припинив це справа, знову прогнав fsck -y, і на цей раз сервер завантажився.
З видимих втрат - злетів симлінк / etc / namedb.
Симлінк зробив, запустив named.
Начебто все на місці і працює.
Але внаслідок повної неосвіченості в області файлових систем мучать мене тепер сумніви - а все-ли тепер з цими самими файловими системами в порядку?
Підкажіть, будь ласка, як правильно і остаточно їх перевірити.
/ Dev / da0p2 on / (ufs, local, journaled soft-updates)
devfs on / dev (devfs, local, multilabel)
/ Dev / da0p4 on / u (ufs, local, journaled soft-updates)
devfs on / var / named / dev (devfs, local, multilabel)
Напевно занадто тупий питання.
Ну добре, а як народ ставиться до fsck_y_enable = "YES" у rc.conf?
Post by A***@public.gmane.org
І заодно, що щодо background_fsck = "NO"?
Post by A***@public.gmane.org
Пишуть, що "YES", який за замовчуванням, може призводити до небажаних наслідків.
Post by A***@public.gmane.org
Ну добре, а як народ ставиться до fsck_y_enable = "YES" у rc.conf?
Я ставлю. З яких міркувань на питання fsck можна відповісти no я не знаю
(Номери inode всіх файлів на пам'ять я все одно не пам'ятаю, а крім inode fsck
нічого не пише), тому краще використовувати fsck -y і не відповідати купу раз yes
Post by A***@public.gmane.org
І заодно, що щодо background_fsck = "NO"?
Пишуть, що "YES", який за замовчуванням, може призводити до небажаних наслідків.
Правильно пишуть. background fsck поганий хоча б тим що створює снапшот. А UFS
снапшоти на великих розділах працюють погано:
- снапшот створюється дуже довго і диск при цьому сильно навантажений
- частина цього часу блокуються будь-які додатки які намагаються звернутися до FS
- частина цього часу блокуються додатки, які намагаються щось писати на
диск.
Ну і після того, як снапшот буде створений, background fsck навантажує диск, заважаючи
нормально роботі додатків (якщо їм теж потрібен диск).
Post by A***@public.gmane.org
/ Dev / da0p2 on / (ufs, local, journaled soft-updates)
devfs on / dev (devfs, local, multilabel)
/ Dev / da0p4 on / u (ufs, local, journaled soft-updates)
devfs on / var / named / dev (devfs, local, multilabel)
Напевно занадто тупий питання.
Ну добре, а як народ ставиться до fsck_y_enable = "YES" у rc.conf?
Добре, треба завжди ставити.
Post by A***@public.gmane.org
І заодно, що щодо background_fsck = "NO"?
Пишуть, що "YES", який за замовчуванням, може призводити до небажаних наслідків.
IMHO, backgroupd_fsck не актуальний для journaled soft-updates.
Воно для НЕ journaled.
Post by A***@public.gmane.org
/ Dev / da0p2 on / (ufs, local, journaled soft-updates)
devfs on / dev (devfs, local, multilabel)
/ Dev / da0p4 on / u (ufs, local, journaled soft-updates)
devfs on / var / named / dev (devfs, local, multilabel)
îÁ × ÅÒÎÏÅ ÓÌÉÛËÏÍ ÔÕÐÏÊ × ÏÐÒÏÓ.
îÕ ÈÏÒÏÛÏ, Á ËÁË ÎÁÒÏÄ ÏÔÎÏÓÉÔÓÑ Ë fsck_y_enable = "YES" × rc.conf?
èÏÒÏÛÏ, ÎÁÄÏ × ÓÅÇÄÁ ÓÔÁ × ÉÔØ.
é ÚÁÏÄÎÏ, ÞÔÏ ÎÁÓÞ £ Ô background_fsck = "NO"?
ðÉÛÕÔ, ÞÔÏ "YES", ËÏÔÏÒÙÊ ÐÏ ÕÍÏÌÞÁÎÉÀ, ÍÏÖÅÔ ÐÒÉ × ÏÄÉÔØ Ë ÎÅÖÅÌÁÔÅÌØÎÙÍ
ÐÏÓÌÅÄÓÔ × ÉÑÍ.
IMHO, backgroupd_fsck ÎÅ ÁËÔÕÁÌÅÎ ÄÌÑ journaled soft-updates.
ïÎÏ ÄÌÑ ÎÅ journaled.
Post by Eugene Grosbein
IMHO, backgroupd_fsck не актуальний для journaled soft-updates.
Воно для НЕ journaled.
Соррі, а чому?
background fsck був придуманий для того, щоб прискорити завантаження системи
в multiuser після крешей, не чекати закінчення fsck.
Це не актуально для журнальованою метаданих, там в нормі просто
відкат журналу і все. А якщо у SUJ виявляється зруйнований навіть журнал,
то тут вже backround fsck зовсім не варто робити - небезпечно, можна паніку зловити,
як показує практика.
Post by Eugene Grosbein
а як народ ставиться до fsck_y_enable = "YES" у rc.conf?
Post by Eugene Grosbein
Добре, треба завжди ставити.
ризикну запропонувати свій варіант:
fsck_y_ без _f_ практично не потрібен
Post by Eugene Grosbein
IMHO, backgroupd_fsck не актуальний для journaled soft-updates.
Воно для НЕ journaled.
з приводу journaled в англомовному handbook-е є дані про те, що при відновленні даних з журналу утиліта виходячи з якихось абсолютно магічних міркувань встановлює для файлу підлягає відновленню статус 0 або 1; і в дефолті (за моїми спостереженнями) для текстових (* .tex) файлів завжди надає їм 0, власне під "0" їх при цьому вичищаючи, тобто в файлі не залишається не тільки останніх змін, там не залишається взагалі нічого
я від journaled відмовився взагалі, а зараз повністю переїжджаю на zfs, але мені легше - у мене десктоп
тема була розпочата з питання про неправильну поведінку сервера.
з усього видно, доведеться все робити з нуля
Post by Roman Goncharuk
а як народ ставиться до fsck_y_enable = "YES" у rc.conf?
Post by Eugene Grosbein
Добре, треба завжди ставити.
Немає такого параметра серед розпізнаються системою параметрів rc.conf
Але при бажанні можна прописати fsck_y_flags = "- f", щоб отримати
в результаті fsck -y -f.
Post by Roman Goncharuk
fsck_y_ без _f_ практично не потрібен
Чому? Навіщо перевіряти свідомо чисті fs, щоб кожен чистий ребут
виконувався як можна довше?
Post by Roman Goncharuk
Post by Eugene Grosbein
а як народ ставиться до fsck_y_enable = "YES" у rc.conf?
Post by Eugene Grosbein
Добре, треба завжди ставити.
fsck_yf_enable = "YES"
background_fsck = "NO"
fsck_y_ без _f_ практично не потрібен
Напевно все ж мова ось про це:
fsck_y_flags = "" # Additional flags for fsck -y
А "fsck_yf_enable" не знайшов навіть в 10.0.
Post by Roman Goncharuk
Post by Eugene Grosbein
IMHO, backgroupd_fsck не актуальний для journaled soft-updates.
Воно для НЕ journaled.
з приводу journaled в англомовному handbook-е є дані про те, що при відновленні даних з журналу утиліта виходячи з якихось абсолютно магічних міркувань встановлює для файлу підлягає відновленню статус 0 або 1; і в дефолті (за моїми спостереженнями) для текстових (* .tex) файлів завжди надає їм 0, власне під "0" їх при цьому вичищаючи, тобто в файлі не залишається не тільки останніх змін, там не залишається взагалі нічого
У первісному повідомленні мова про "soft update journaling", а ви про нього ж
або про gjournal?
tunefs: soft update journaling: (-j)
tunefs: gjournal: (-J)
Post by Roman Goncharuk
я від journaled відмовився взагалі, а зараз повністю переїжджаю на zfs, але мені легше - у мене десктоп
тема була розпочата з питання про неправильну поведінку сервера.
з усього видно, доведеться все робити з нуля
Post by Ð ?? Ð »Ð ° Ð'Ð¸Ð¼Ð¸Ñ ?? Ð ?? Ñ ?? Ñ ?? Ð · Ðμнко
fsck_y_flags = "" # Additional flags for fsck -y
А "fsck_yf_enable" не знайшов навіть в 10.0.
ага, я можу і помилятися (система не сигналила,
а якщо і запустилася автоматично я все одно
вивантажувати і вручну запускаю fsck -yf)
а рядок в конфіги тримаю за інерцією
Post by Ð ?? Ð »Ð ° Ð'Ð¸Ð¼Ð¸Ñ ?? Ð ?? Ñ ?? Ñ ?? Ð · Ðμнко
У первісному повідомленні мова про "soft update journaling"
да, я про "soft update journaling" і про триразовому
відновленні текстового файлу з pdf-а,
як раз треба було працювати з величезним файлом
ясна річ, що власні помилки вчать більше ніж абзац в підручнику
Post by Ð ?? Ð »Ð ° Ð'Ð¸Ð¼Ð¸Ñ ?? Ð ?? Ñ ?? Ñ ?? Ð · Ðμнко
tunefs: soft update journaling: (-j)
ось саме так я і відмовився від використання журналу
софтапдейт повільніше, але незрівнянно надійніше
Post by Ð ?? Ð »Ð ° Ð'Ð¸Ð¼Ð¸Ñ ?? Ð ?? Ñ ?? Ñ ?? Ð · Ðμнко
fsck_y_flags = "" # Additional flags for fsck -y
fsck_y_flags = "f" встановив і хочу продовжити бесіду
справа в тому, що даний прапор (от уже не знаю як там в документації) зовсім не форсує перевірку ФС щоразу при завантаженні --- були тут побоювання у кого-то --- спеціально витримав паузу і провів кілька завантажень ос в звичайному побутовому режимі; для природності, так би мовити, спостережень
перевірка ініціюється зовсім по іншому (durty по-моєму)
а fsck_y_flags = "f" форсує перевірку всіх елементів ФС,
навіть тих, які позначені як чисті (як і 'fsck -yf'),
і, так. несподіванки бувають при кожній перевірці --- перевірено
Post by Roman Goncharuk
Post by Ð ?? Ð »Ð ° Ð'Ð¸Ð¼Ð¸Ñ ?? Ð ?? Ñ ?? Ñ ?? Ð · Ðμнко
fsck_y_flags = "" # Additional flags for fsck -y
fsck_y_flags = "f" встановив і хочу продовжити бесіду
справа в тому, що даний прапор (от уже не знаю як там в документації)
А прочитати man fsck?
Post by Roman Goncharuk
зовсім не форсує перевірку ФС щоразу при завантаженні --- були тут побоювання у кого-то ---
спеціально витримав паузу і провів кілька завантажень ос в звичайному побутовому режимі;
Тому що настройка взагалі не спрацювала, треба "-f", а не "f".
Post by Roman Goncharuk
перевірка ініціюється зовсім по іншому (durty по-моєму)
а fsck_y_flags = "f" форсує перевірку всіх елементів ФС,
навіть тих, які позначені як чисті (як і 'fsck -yf'),
Про це і мова. Навіщо воно?
Post by Roman Goncharuk
і, так. несподіванки бувають при кожній перевірці --- перевірено
Це у вас залізо дивне або система криво встановлена -
таке теж можливо. Наприклад, можна зробити один gjournal на весь
диск і вже на ньому розбиття на розділи і кілька
файлових систем UFS - зовні все буде виглядати добре,
але будуть постійні проблеми з fsck, тому що це некоректне
розбиття (gjournal повинен бути свій у кожної fs).
Vasiliy P. Melnik
fsck_y_enable = "NO" # Set to YES to do fsck -y if the initial preen fails.
fsck_y_flags = "" # Additional flags for fsck -y
Так без fsck_y_enable = "YES" прапори точно працювати не будуть. А чітко
прописано if the initial preen fails.
З.И. можна почитати /etc/rc.d/fsck - там досить зрозуміло все
Post by Roman Goncharuk
Post by Ð ?? Ð »Ð ° Ð'Ð¸Ð¼Ð¸Ñ ?? Ð ?? Ñ ?? Ñ ?? Ð · Ðμнко
fsck_y_flags = "" # Additional flags for fsck -y
fsck_y_flags = "f" встановив і хочу продовжити бесіду
справа в тому, що даний прапор (от уже не знаю як там в документації) зовсім не форсує перевірку ФС щоразу при завантаженні --- були тут побоювання у кого-то --- спеціально витримав паузу і провів кілька завантажень ос в звичайному побутовому режимі; для природності, так би мовити, спостережень
перевірка ініціюється зовсім по іншому (durty по-моєму)
а fsck_y_flags = "f" форсує перевірку всіх елементів ФС,
навіть тих, які позначені як чисті (як і 'fsck -yf'),
і, так. несподіванки бувають при кожній про
Post by Vasiliy P. Melnik
Так без fsck_y_enable = "YES" прапори точно працювати не будуть. А чітко
прописано if the initial preen fails.
З.И. можна почитати /etc/rc.d/fsck - там досить зрозуміло все
ось рядки з конфіга
і не запускається перевірка при кожному старті системи
може бути помилка ще десь?
Vasiliy P. Melnik
Post by Roman Goncharuk
Post by Vasiliy P. Melnik
Так без fsck_y_enable = "YES" прапори точно працювати не будуть. А чітко
прописано if the initial preen fails.
З.И. можна почитати /etc/rc.d/fsck - там досить зрозуміло все
ось рядки з конфіга
fsck_y_enable = "YES"
fsck_y_flags = "- f"
background_fsck = "NO"
. і не запускається перевірка при кожному старті системи
так і не повинна вона кожен раз запускатися
Set to YES to do fsck -y if the initial preen fails.
Я не знаю англійської, але суть в тому, що має запуститися fsck,
якщо при ініціалізації сис