[sisyphus] XFS filesystem crash

[sisyphus] XFS filesystem crash

[Epiphanov Sergei]

Есть вопрос: пару раз по случайности нажимал на кнопку Reset вместо Power 
Off. После перезагрузки почему-то оказывался начисто запоротым файл 
/etc/fstab. После тестирования через систему rpm ничего другого 
проблемного не находил. Система: Сизиф от начала декабря, ядро 
up-2.4.22-alt12. 

Структура:
/		xfs 
/boot	ext2
/home	xfs
/var		xfs
/usr		xfs

В последний раз вообще комично: набрал sync, после его отработки нажал 
Reset. /etc/fstab всё равно превратился в кашу символов.

В чем может быть дело?

-- 
С уважением, Епифанов Сергей

Re: [sisyphus] XFS filesystem crash

[Eugene Ostapets]

Epiphanov Sergei пишет:
> Есть вопрос: пару раз по случайности нажимал на кнопку Reset вместо Power 
> Off. После перезагрузки почему-то оказывался начисто запоротым файл 
> /etc/fstab. После тестирования через систему rpm ничего другого 
> проблемного не находил. Система: Сизиф от начала декабря, ядро 
> up-2.4.22-alt12. 
> 
> Структура:
> /		xfs 
> /boot	ext2
> /home	xfs
> /var		xfs
> /usr		xfs
> 
> В последний раз вообще комично: набрал sync, после его отработки нажал 
> Reset. /etc/fstab всё равно превратился в кашу символов.
> 
> В чем может быть дело?
> 
А чего еще можно ждать от XFS? Оно рассчитана на идеальные условия 
работы. В реальных ты будешь постоянно терять fstab, inittab, XF86Config...
-- 
С уважением,
Евгений Остапец
+380 44 459 28 79
http://www.unisoft.com.ua

Re: [sisyphus] XFS filesystem crash

[Alexei V. Mezin]

Hello Epiphanov,

Tuesday, December 16, 2003, 11:58:47 AM, you wrote:


ES> В последний раз вообще комично: набрал sync, после его отработки нажал 
ES> Reset. /etc/fstab всё равно превратился в кашу символов.

Без sync часто воспроизводится на xfs. Может это встроенная фича
такая? С sync не пробовал.




-- 
Best regards,
 Alexei V. Mezin                            mailto:mezin@ntmdt.ru

Re: [sisyphus] XFS filesystem crash

[Epiphanov Sergei]

В сообщении от 16 Декабрь 2003 12:40 Eugene Ostapets написал:
> Epiphanov Sergei пишет:
> > Есть вопрос: пару раз по случайности нажимал на кнопку Reset вместо
> > Power Off. После перезагрузки почему-то оказывался начисто запоротым
> > файл /etc/fstab. После тестирования через систему rpm ничего другого
> > проблемного не находил. Система: Сизиф от начала декабря, ядро
> > up-2.4.22-alt12.
> >
> > Структура:
> > /		xfs
> > /boot	ext2
> > /home	xfs
> > /var		xfs
> > /usr		xfs
> >
> > В последний раз вообще комично: набрал sync, после его отработки нажал
> > Reset. /etc/fstab всё равно превратился в кашу символов.
> >
> > В чем может быть дело?
>
> А чего еще можно ждать от XFS? Оно рассчитана на идеальные условия
> работы. В реальных ты будешь постоянно терять fstab, inittab,
> XF86Config...

Но почему тогда только один файл рушится, причём совершенно одинаково? 
Никто его не правил, тем более, что порушилось сразу после команды sync. 
Все файлы, что до этого качал с usb-flash на раздел с xfs - в полном 
порядке: и размер, и содержание. А /etc/fstab - мало того, что размер раза 
в полтора увеличился, так ещё и вместо обычного текста символ с кодом 1 
заполонил весь файл...

Может, usb hotplug-агент подгадил?

-- 
С уважением, Епифанов Сергей

Re: [sisyphus] XFS filesystem crash

[Eugene Ostapets]

Epiphanov Sergei пишет:
> В сообщении от 16 Декабрь 2003 12:40 Eugene Ostapets написал:
> 
>>Epiphanov Sergei пишет:
>>
> 
> Но почему тогда только один файл рушится, причём совершенно одинаково? 
> Никто его не правил, тем более, что порушилось сразу после команды sync. 
> Все файлы, что до этого качал с usb-flash на раздел с xfs - в полном 
> порядке: и размер, и содержание. А /etc/fstab - мало того, что размер раза 
> в полтора увеличился, так ещё и вместо обычного текста символ с кодом 1 
> заполонил весь файл...
Это просто повезло...
> 
> Может, usb hotplug-агент подгадил?
Ага, при монтировании через hotplug изменялся /etc/fstab... А на XFS 
sync работает как-то странно, я проверял устойчивость файловых систем и 
нажимал reset после выполнения команды sync - всегда полная каша в 
измененных файлах. ReiserFS и EXT3 намного устойчивее...
> 


-- 
С уважением,
Евгений Остапец
+380 44 459 28 79
http://www.unisoft.com.ua

Re: [sisyphus] XFS filesystem crash

[Epiphanov Sergei]

В сообщении от 16 Декабрь 2003 14:26 Eugene Ostapets написал:

> > Может, usb hotplug-агент подгадил?
>
> Ага, при монтировании через hotplug изменялся /etc/fstab... А на XFS
> sync работает как-то странно, я проверял устойчивость файловых систем и
> нажимал reset после выполнения команды sync - всегда полная каша в
> измененных файлах. ReiserFS и EXT3 намного устойчивее...

Придется не согласиться по поводу устойчивости файловых систем. Дело в том, 
что в своё время я поставил Master2.0 (а потом и на Master2.2) на ReiserFS 
и через некоторое время заметил, что некоторые файлы начали потихоньку 
накрываться. Причём файлы накрывались совершенно случайно и со сбоями по 
питанию это не было связано, только с перезагрузкой системы. Пришлось в 
срочном порядке переходить на XFS (JFS и ext3 не устраивали по некоторым 
причинам: нельзя было создать файл >2Гбайт). До недавнего времени всё было 
в порядке. Пока не нажал Reset...

Вот только об одном жалею: на XFS нельзя создать жёсткую ссылку на каталог 
даже под root, а на ext2(ext3) можно.

-- 
С уважением, Епифанов Сергей

[sisyphus] Re: XFS filesystem crash

[Michael Shigorin]

On Tue, Dec 16, 2003 at 02:54:28PM +0300, Epiphanov Sergei wrote:
> Вот только об одном жалею: на XFS нельзя создать жёсткую ссылку
> на каталог даже под root, а на ext2(ext3) можно.

И как же, позвольте осведомиться?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [sisyphus] Re: XFS filesystem crash

[Epiphanov Sergei]

В сообщении от 16 Декабрь 2003 15:25 Michael Shigorin написал:
> On Tue, Dec 16, 2003 at 02:54:28PM +0300, Epiphanov Sergei wrote:
> > Вот только об одном жалею: на XFS нельзя создать жёсткую ссылку
> > на каталог даже под root, а на ext2(ext3) можно.
>
> И как же, позвольте осведомиться?

Сам не создавал (нет возможности проверить), а в man по ln написано, что 
есть ключ -d, который позволит всё-таки создать данную жёсткую ссылку на 
каталог.

-- 
С уважением, Епифанов Сергей

Re: [sisyphus] XFS filesystem crash

[Alexey Morozov]

[-- Attachment #1: Type: text/plain, Size: 207 bytes --]

On Tue, Dec 16, 2003 at 02:54:28PM +0300, Epiphanov Sergei wrote:
> Вот только об одном жалею: на XFS нельзя создать жёсткую ссылку на каталог 
> даже под root, а на ext2(ext3) можно.
?? "Но как, поручик??"

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] XFS filesystem crash

[Eugene Ostapets]

Epiphanov Sergei пишет:
> В сообщении от 16 Декабрь 2003 14:26 Eugene Ostapets написал:
> 
> 
>>>Может, usb hotplug-агент подгадил?
>>
> 
> Придется не согласиться по поводу устойчивости файловых систем. Дело в том, 
> что в своё время я поставил Master2.0 (а потом и на Master2.2) на ReiserFS 
> и через некоторое время заметил, что некоторые файлы начали потихоньку 
> накрываться. Причём файлы накрывались совершенно случайно и со сбоями по 
> питанию это не было связано, только с перезагрузкой системы. Пришлось в 
> срочном порядке переходить на XFS (JFS и ext3 не устраивали по некоторым 
> причинам: нельзя было создать файл >2Гбайт). До недавнего времени всё было 
> в порядке. Пока не нажал Reset...
> 
Ну тогда я вам посоветую потестировать память, reiserfs у меня за 3 года 
использования под нагрузкой не сыпался... А вот при сбоях памяти 
(разогнанный проц или шина) сыпятся все файловые системы без исключений, 
но по разному - reiserfs накрывается фатально, а на XFS обычно пофайлово...

> Вот только об одном жалею: на XFS нельзя создать жёсткую ссылку на каталог 
> даже под root, а на ext2(ext3) можно.
А в чем перимущество перед soft link? кроме конечно недостатка в потере 
места?
-- 
С уважением,
Евгений Остапец
+380 44 459 28 79
http://www.unisoft.com.ua

[sisyphus] Re: XFS filesystem crash

[Michael Shigorin]

On Tue, Dec 16, 2003 at 02:35:44PM +0200, Eugene Ostapets wrote:
> Ну тогда я вам посоветую потестировать память, reiserfs у меня за 3 года 
> использования под нагрузкой не сыпался... А вот при сбоях памяти 
> (разогнанный проц или шина) сыпятся все файловые системы без исключений, 
> но по разному - reiserfs накрывается фатально, а на XFS обычно пофайлово...

Кстати, в недавнем интервью Ганс сказал по крайней мере одну
применимую к нам вещь -- fsck.reiserfs действительно стоит
обновить.

И я так и не понял -- у нас сейчас data-logging-and-quota patch
на reiserfs ложится и собирается или нет?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[sisyphus] Re: XFS filesystem crash

[Michael Shigorin]

On Tue, Dec 16, 2003 at 03:30:47PM +0300, Epiphanov Sergei wrote:
> > > Вот только об одном жалею: на XFS нельзя создать жёсткую ссылку
> > > на каталог даже под root, а на ext2(ext3) можно.
> > И как же, позвольте осведомиться?
> Сам не создавал (нет возможности проверить), а в man по ln
> написано, что есть ключ -d, который позволит всё-таки создать
> данную жёсткую ссылку на каталог.

Насколько я помню -- ее убьет следующий же fsck.

См. тж. 

find . -type d -maxdepth 1 | wc -l
ls -ld . | awk '{print $2;}'

:)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [sisyphus] Re: XFS filesystem crash

[Epiphanov Sergei]

В сообщении от 16 Декабрь 2003 15:51 Michael Shigorin написал:
> On Tue, Dec 16, 2003 at 03:30:47PM +0300, Epiphanov Sergei wrote:
> > > > Вот только об одном жалею: на XFS нельзя создать жёсткую ссылку
> > > > на каталог даже под root, а на ext2(ext3) можно.
> > >
> > > И как же, позвольте осведомиться?
> >
> > Сам не создавал (нет возможности проверить), а в man по ln
> > написано, что есть ключ -d, который позволит всё-таки создать
> > данную жёсткую ссылку на каталог.
>
> Насколько я помню -- ее убьет следующий же fsck.

Под Castle Beta3 эти ссылки существовали на ext2. Не знаю, как сейчас.

-- 
С уважением, Епифанов Сергей

Re: [sisyphus] Re: XFS filesystem crash

[Alexey Morozov]

[-- Attachment #1: Type: text/plain, Size: 289 bytes --]

On Tue, Dec 16, 2003 at 03:30:47PM +0300, Epiphanov Sergei wrote:
> > И как же, позвольте осведомиться?
> Сам не создавал (нет возможности проверить), а в man по ln написано, что 
> есть ключ -d, который позволит всё-таки создать данную жёсткую ссылку на 
> каталог.
Доверяй, но проверяй?

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] XFS filesystem crash

[Slava Garelin]

On Tue, 16 Dec 2003 11:40:07 +0200
Eugene Ostapets <support@unisoft.com.ua> wrote:

> А чего еще можно ждать от XFS? Оно рассчитана на идеальные условия 
> работы. В реальных ты будешь постоянно терять fstab, inittab,
> XF86Config...-- 

А вот если не сложно развить мысль об изнеженности XFS? А то у меня в
последнее время ряд вопросов к ReiserFS, я на XFS поглядываю...

-- 
Slava Garelin

Re: [sisyphus] XFS filesystem crash

[Igor Solovyov]

Hi!
On Tue, 16 Dec 2003 14:54:28 +0300
Epiphanov Sergei <serpiph@entek.ru> wrote:

> > ReiserFS и EXT3 намного устойчивее...
> 
> Придется не согласиться по поводу устойчивости файловых систем. Дело в том, 
> что в своё время я поставил Master2.0 (а потом и на Master2.2) на ReiserFS 
> и через некоторое время заметил, что некоторые файлы начали потихоньку 
> накрываться. Причём файлы накрывались совершенно случайно и со сбоями по 
> питанию это не было связано, только с перезагрузкой системы....

Я очень давно использую ReiserFS и не только в дистрибутивах от ALT.
Описанных проблем никогда не испытывал. Может все-таки это не проблемы
файловых систем? Может все-таки это проблемы железа?
Были бы проблемы не связанные с железом, а чисто проблемы файловых
систем, они вылазили у всех подряд, а это явно не так.

-- 
Best regards!
Igor Solovyov
System/network administrator
JSC CB "Zlatkombank"

Re: [sisyphus] XFS filesystem crash

[info]

16 Декабрь 2003 17:57, Igor Solovyov написал:
> Hi!
> On Tue, 16 Dec 2003 14:54:28 +0300
>
> Epiphanov Sergei <serpiph@entek.ru> wrote:
> > > ReiserFS и EXT3 намного устойчивее...
> >
> > Придется не согласиться по поводу устойчивости файловых
> > систем. Дело в том, что в своё время я поставил Master2.0
> > (а потом и на Master2.2) на ReiserFS и через некоторое
> > время заметил, что некоторые файлы начали потихоньку
> > накрываться. Причём файлы накрывались совершенно случайно и
> > со сбоями по питанию это не было связано, только с
> > перезагрузкой системы....
>
> Я очень давно использую ReiserFS и не только в дистрибутивах
> от ALT. Описанных проблем никогда не испытывал. Может
> все-таки это не проблемы файловых систем? Может все-таки это
> проблемы железа? Были бы проблемы не связанные с железом, а
> чисто проблемы файловых систем, они вылазили у всех подряд, а
> это явно не так.

Полностью поддерживаю: у нас куча дектопов на рейзерах с 2000-го 
года, перегружаются - понятное дело как (каждый день, да не по 
одному разу), а иногда и жестко перегружаются - сиречь 
вырубанием питания, если юзер - бревно. И за все это время ни 
одной проблемы с потерей файлов никогда не было. 

Может, у вас рейзеры старой версии (3.3.5, кажись)? Там - да, 
говорят , такие проблемы были

Георгий 

Re: [sisyphus] XFS filesystem crash

[info]

16 Декабрь 2003 18:17, info написал:
Кстати, вдогонку - hdparm не пробовали? В таком, например, виде:
/sbin/hdparm -c 3,
сиречь "32-bit data transfers with a special sync sequence", как 
написано в man hdparm.

Георгий

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Tue, Dec 16, 2003 at 01:26:20PM +0200, Eugene Ostapets wrote:

 > Ага, при монтировании через hotplug изменялся /etc/fstab... А на XFS 
 > sync работает как-то странно, я проверял устойчивость файловых систем и 
 > нажимал reset после выполнения команды sync - всегда полная каша в 
 > измененных файлах. ReiserFS и EXT3 намного устойчивее...

Проверьте подряд 2 sync'а. Дело в том, что первый sync начинает
асинхронный сброс буферов (т.е. вываливается немедленно, но буферы ещё не
сбросил). Второй sync завершается _только_ после сброса всех буферов.
 
-- 
С уважением, Денис

http://freesource.info

Re: [sisyphus] Re: XFS filesystem crash

[Serge Pavlovsky]

В ?? 16.12.2003, в 18:42, Денис Смирнов пишет:
> On Tue, Dec 16, 2003 at 01:26:20PM +0200, Eugene Ostapets wrote:
> 
>  > Ага, при монтировании через hotplug изменялся /etc/fstab... А на XFS 
>  > sync работает как-то странно, я проверял устойчивость файловых систем и 
>  > нажимал reset после выполнения команды sync - всегда полная каша в 
>  > измененных файлах. ReiserFS и EXT3 намного устойчивее...
> 
> Проверьте подряд 2 sync'а. Дело в том, что первый sync начинает
> асинхронный сброс буферов (т.е. вываливается немедленно, но буферы ещё не
> сбросил). Второй sync завершается _только_ после сброса всех буферов.

man 3 sync с этим не согласен
-- 
Serge Pavlovsky <pal@interexc.com>

Re: [sisyphus] Re: XFS filesystem crash

[Serge Pavlovsky]

В ?? 16.12.2003, в 20:43, Serge Pavlovsky пишет:
> man 3 sync с этим не согласен

т.е. 2
-- 
Serge Pavlovsky <pal@interexc.com>

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Tue, Dec 16, 2003 at 08:43:08PM +0200, Serge Pavlovsky wrote:

 >> Проверьте подряд 2 sync'а. Дело в том, что первый sync начинает
 >> асинхронный сброс буферов (т.е. вываливается немедленно, но буферы ещё не
 >> сбросил). Второй sync завершается _только_ после сброса всех буферов.
 > man 3 sync с этим не согласен

Насколько мне известно такое поведение характерно только для xfs :(
 
-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Tue, Dec 16, 2003 at 04:46:55PM +0200, Slava Garelin wrote:

 >> А чего еще можно ждать от XFS? Оно рассчитана на идеальные условия 
 >> работы. В реальных ты будешь постоянно терять fstab, inittab,
 >> XF86Config...-- 
 > А вот если не сложно развить мысль об изнеженности XFS? А то у меня в
 > последнее время ряд вопросов к ReiserFS, я на XFS поглядываю...

Не то чтобы она была совсем уж изнеженой, просто она изначально была
рассчитана на более другое железо и более другое использование. Только
сумасшедший при покупке системы от SGI начнёт экономить на UPS, а у самих
этих машин наверняка (это моё предположение) и блоки питания далеко не
noname, и память тестируют по-человечески перед тем как продать. Кроме
того структура как самой fs, так и её кода заметно сложнее чем у ext3,
поэтому сбой той же памяти окажет _заметно_ более крутые последствия.
Возможно это можно было бы избежать наделав перепроверок в коде,
отключаемых при компиляции, но сейчас этого нет.

Резюме: на нынешнем ширпотребном железе использовать XFS можно (и нужно)
тогда, и только тогда, когда:

1. есть хороший UPS (не стоит на нём экономить, лучше брать APC)
2. хороший блок питания (например в корпусе от InWin)
3. память была протестирована

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

Ещё один момент --  ReiserFS по принципиальным соображением не умеет
корректно обрабатывать ситуации вроде сбоев HDD. Посему его использование
оправдано тогда, и только тогда, когда он кроме вышеперечисленого лежит на
RAID-массиве. Как к этому относится XFS мне неизвестно, однако думаю что
хоть и лучше, но ненамного.

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

XFS -- в первую очередь работа с БОЛЬШИМИ объёмами данных, под БОЛЬШИМИ
нагрузками, и при этом с хорошей производительностью, умеет с большой
эффективностью использовать возможности хорошего железа. То есть -- эта
файловая система лучше всех масштабируется вверх.

ReiserFS -- это серьёзный рывок вперёд, кое где это файловая система
опережающая своё время, однако, с моей точки зрения, не слишком пригодная
_пока_ к применению по причине привычки пользователей к откровенно
дерьмовому железу (которое и используется подавляющим большинством), а
также по той простой причиной, что язык C непригоден для написания
настолько сложного кода, а замены ему в системном программировании
попросту нет, увы.

Общий вывод:
 - если данные очень дороги, то ext3 с data=journal это то, что вам надо
 - если нужна ещё и высокая производительность, то XFS и _обязательно_
   протестировать оборудование (хотя, на самом деле, тестировать надо
   любую железку после покупки, и покупать, соответственно, там где её
   если что согласятся обменять)
 - если нужна высокая производительность на большом количестве файлов
   небольшого размера (кэш прокси-сервера, например, /tmp, nntp-спул),
   тогда ReiserFS оптимальный выбор.

В любом случае, если есть возможность, то нынче стоит использовать как
минимум software RAID-5.

-- 
С уважением, Денис

http://freesource.info

[sisyphus] [JT] Re: XFS filesystem crash

[Michael Shigorin]

On Tue, Dec 16, 2003 at 11:31:54PM +0300, Денис Смирнов wrote:
> 1. есть хороший UPS (не стоит на нём экономить, лучше брать APC)

Если не экономить, а брать лучше -- то это Liebert скорее. :)

> 2. хороший блок питания (например в корпусе от InWin)

Fortron (или Chieftec на худой конец).

> 3. память была протестирована

memtest86 %)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [sisyphus] Re: XFS filesystem crash

[Vitaly Lipatov]

On 16 Декабрь 2003 15:49, Michael Shigorin wrote:
> Кстати, в недавнем интервью Ганс сказал по крайней мере одну
> применимую к нам вещь -- fsck.reiserfs действительно стоит
> обновить.
А у нас, насколько я понимаю, в пакете лежат очень старые вещи и 
никто ими не занимается?

-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! LaTeX! LyX!

Re: [sisyphus] XFS filesystem crash

[Vitaly Lipatov]

On 16 Декабрь 2003 18:17, info wrote:

> Полностью поддерживаю: у нас куча дектопов на рейзерах с
> 2000-го года, перегружаются - понятное дело как (каждый день,
> да не по одному разу), а иногда и жестко перегружаются -
> сиречь вырубанием питания, если юзер - бревно. И за все это
> время ни одной проблемы с потерей файлов никогда не было.
Нет, проблема есть. Накрывается inittab (из-за hotplug?),
XF86Config - неясно почему, ~/.../kmailrc - при вырубании после 
выхода из kmail, сама файловая система бывает портится до 
необходимости fsck...
Ядро >=2.4.20, reiserfs изначально 3.6

-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! LaTeX! LyX!

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Tue, Dec 16, 2003 at 11:17:16PM +0200, Michael Shigorin wrote:

 >> 1. есть хороший UPS (не стоит на нём экономить, лучше брать APC)
 > Если не экономить, а брать лучше -- то это Liebert скорее. :)

Выше было сказано про "для дома" :) APC всё-таки на каждом углу продаются.
 
 >> 2. хороший блок питания (например в корпусе от InWin)
 > Fortron (или Chieftec на худой конец).

Любопытно, откуда данные? Цены на Fortron хоть и не маленькие, но вполне
в разумном диапазоне, так что если по сравнению с InWin есть заметные
преимущества -- мои приоритеты изменятся.

 >> 3. память была протестирована
 > memtest86 %)

Им, родимым :)
 
-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Tue, Dec 16, 2003 at 07:42:40PM +0300, Денис Смирнов wrote:

 >> Ага, при монтировании через hotplug изменялся /etc/fstab... А на XFS 
 >> sync работает как-то странно, я проверял устойчивость файловых систем и 
 >> нажимал reset после выполнения команды sync - всегда полная каша в 
 >> измененных файлах. ReiserFS и EXT3 намного устойчивее...
 > Проверьте подряд 2 sync'а. Дело в том, что первый sync начинает
 > асинхронный сброс буферов (т.е. вываливается немедленно, но буферы ещё не
 > сбросил). Второй sync завершается _только_ после сброса всех буферов.

Так, я вдумчиво прочитал man sync, и понял что был не прав. Никакой
информации о двойном sync для реального сброса данных я там не нашёл :(
Сие есть серьёзная проблема -- под кэш часто используется много места, и
даже при штатной перезагрузке вероятна ситуация, когда кэш сброшен на диск
не будет.

Или я что-то неправильно понимаю?
 
-- 
С уважением, Денис

http://freesource.info

Re: [sisyphus] Re: XFS filesystem crash

[Epiphanov Sergei]

В сообщении от 16 Декабрь 2003 19:42 Денис Смирнов написал:
> On Tue, Dec 16, 2003 at 01:26:20PM +0200, Eugene Ostapets wrote:
>  > Ага, при монтировании через hotplug изменялся /etc/fstab... А на XFS
>  > sync работает как-то странно, я проверял устойчивость файловых систем
>  > и нажимал reset после выполнения команды sync - всегда полная каша в
>  > измененных файлах. ReiserFS и EXT3 намного устойчивее...
>
> Проверьте подряд 2 sync'а. Дело в том, что первый sync начинает
> асинхронный сброс буферов (т.е. вываливается немедленно, но буферы ещё
> не сбросил). Второй sync завершается _только_ после сброса всех буферов.

А с какой стати он должен _так_ странно работать? Что за "разумные" 
действия? На то он и sync, чтобы всё сбросить на винт.

У меня на XFS не так, пока всё на винт не сохранится, sync не вываливается 
(по личным наблюдениям за системой).

-- 
С уважением, Епифанов Сергей

Re: [sisyphus] XFS filesystem crash

[Maxim.Savrilov]

[-- Attachment #1: Type: text/plain, Size: 877 bytes --]

On Tue, 16 Dec 2003 16:46:55 +0200
Slava Garelin <garelin@ukr.net> wrote:

> On Tue, 16 Dec 2003 11:40:07 +0200
> Eugene Ostapets <support@unisoft.com.ua> wrote:
> 
> > А чего еще можно ждать от XFS? Оно рассчитана на идеальные условия 
> > работы. В реальных ты будешь постоянно терять fstab, inittab,
> > XF86Config...-- 
> 
> А вот если не сложно развить мысль об изнеженности XFS? А то у меня в
> последнее время ряд вопросов к ReiserFS, я на XFS поглядываю...


кто бы мне это объяснил:
(при том, что вчера я делал apt-get install --reinstall dev)

$ rpm -V dev | fgrep -i отсутствует | wc -l
    161


/dev/hdb1 on / type ext3 (rw)

и такое постоянно и не на одной машине

$ rpm -V dev | fgrep -i отсутствует | wc -l
    163

особенно любопытно
отсутствует /dev/hda1
при том, что на нем рутовая партиция

-- 
Don't tell anyone I'm free.

[-- Attachment #2: Type: application/pgp-signature, Size: 307 bytes --]

Re: [sisyphus] XFS filesystem crash

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 942 bytes --]

* Maxim.Savrilov@socenter.ru <Maxim.Savrilov@socenter.ru> [031217 10:43]:
> кто бы мне это объяснил:
> (при том, что вчера я делал apt-get install --reinstall dev)

> $ rpm -V dev | fgrep -i отсутствует | wc -l
>     161
У меня были более весёлые глюки (тоже на ext3):

ls -1 /dev/ | sort | uniq -d

выдавал непустой результат...

Система - установлена как Spring 2001 года два-три назад, с тех
пор постоянные dist-upgrade, раздел изначально был ext2, потом
добавил журнал (грузился с rescue).

Я бы на Вашем месте загрузился с rescue, fsck'нул бы систему,
убил бы /dev на разделе и по новой бы его поставил...

P.S. Максим, и пожалуйста положите свой pgp ключ на какой-ньдь
публичный keyserver...

-- 
Regards, Sir Raorn.
-------------------
> Это достоинство.  Чем больше пакетов будет завязано на Гном и GTK, тем
> труднее будет отдавать несправедливое предпочтение КДЕ и Qt (Compact).
mount /dev/dikonov /mnt/talk-room
		-- avp in devel@

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[sisyphus] Re: XFS filesystem crash

[Michael Shigorin]

On Wed, Dec 17, 2003 at 02:55:09AM +0300, Денис Смирнов wrote:
>  > Проверьте подряд 2 sync'а. Дело в том, что первый sync
>  > начинает асинхронный сброс буферов (т.е. вываливается
>  > немедленно, но буферы ещё не сбросил). Второй sync
>  > завершается _только_ после сброса всех буферов.
> Так, я вдумчиво прочитал man sync, и понял что был не прав.
> Никакой информации о двойном sync для реального сброса данных я
> там не нашёл :(

Это старая юниксовая идиома, которая, кажется, в Немет
рассматривалась как соответствующая действительности все реже.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[sisyphus] Re: XFS filesystem crash

[Michael Shigorin]

On Wed, Dec 17, 2003 at 02:28:35AM +0300, Vitaly Lipatov wrote:
> > Кстати, в недавнем интервью Ганс сказал по крайней мере одну
> > применимую к нам вещь -- fsck.reiserfs действительно стоит
> > обновить.
> А у нас, насколько я понимаю, в пакете лежат очень старые вещи
> и никто ими не занимается?

Ага.  Заодно был бы рад отдать в надежные руки parted.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[sisyphus] Re: XFS filesystem crash

[Michael Shigorin]

On Wed, Dec 17, 2003 at 02:52:38AM +0300, Денис Смирнов wrote:
>  >> 1. есть хороший UPS (не стоит на нём экономить, лучше брать APC)
>  > Если не экономить, а брать лучше -- то это Liebert скорее. :)
> Выше было сказано про "для дома" :) APC всё-таки на каждом углу продаются.

Домой -- APC?  (пользую некий Victron и все в полном ажуре)

>  >> 2. хороший блок питания (например в корпусе от InWin)
>  > Fortron (или Chieftec на худой конец).
> Любопытно, откуда данные? Цены на Fortron хоть и не маленькие,
> но вполне в разумном диапазоне, так что если по сравнению с
> InWin есть заметные преимущества -- мои приоритеты изменятся.

От сборщиков, которые не поленились собрать стенд и погонять
разные блоки.  Этот -- единственный, который не проваливался под
нагрузкой, соответствующей заявленным ТТХ (ВА по напряжениям,
суммарная мощность) и который реально переживает короткие между
любыми выходами.

Ну и пропеллеры.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [sisyphus] Re: XFS filesystem crash

[Serge Pavlovsky]

В ?? 17.12.2003, в 01:55, Денис Смирнов пишет:
> On Tue, Dec 16, 2003 at 07:42:40PM +0300, Денис Смирнов wrote:
> 
> Так, я вдумчиво прочитал man sync, и понял что был не прав. Никакой
> информации о двойном sync для реального сброса данных я там не нашёл :(
> Сие есть серьёзная проблема -- под кэш часто используется много места, и
> даже при штатной перезагрузке вероятна ситуация, когда кэш сброшен на диск
> не будет.
> 
> Или я что-то неправильно понимаю?

помоему там русским по белому сказано, что пока все не сбросит, не
вернется
 
-- 
Serge Pavlovsky <pal@interexc.com>

Re: [sisyphus] Re: XFS filesystem crash

[Denis S. Filimonov]

On Wednesday 17 December 2003 05:55, Денис Смирнов wrote:
>
> Так, я вдумчиво прочитал man sync, и понял что был не прав. Никакой
> информации о двойном sync для реального сброса данных я там не нашёл
> :( Сие есть серьёзная проблема -- под кэш часто используется много
> места, и даже при штатной перезагрузке вероятна ситуация, когда кэш
> сброшен на диск не будет.
>
> Или я что-то неправильно понимаю?
разумеется не весь кэш сливается на диск, а только измененные (dirty) 
блоки, а их как правило относительно мало.

-- 
Sincerely,
Denis.

Re: [sisyphus] Re: XFS filesystem crash

[Slava Garelin]

On Tue, 16 Dec 2003 23:31:54 +0300
Денис Смирнов <mithraen@freesource.info> wrote:

> On Tue, Dec 16, 2003 at 04:46:55PM +0200, Slava Garelin wrote:

>  > А вот если не сложно развить мысль об изнеженности XFS? А то у меня
>  > в последнее время ряд вопросов к ReiserFS, я на XFS поглядываю...
> 
> Не то чтобы она была совсем уж изнеженой, просто она изначально была
> рассчитана на более другое железо и более другое использование.
...

Большое спасибо за развернутый ответ!

-- 
Slava Garelin

[sisyphus] Re: XFS filesystem crash

[Vitaly Ostanin]

[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]

On Wed, 17 Dec 2003 02:32:57 +0300
Vitaly Lipatov <LAV@VL3143.spb.edu> wrote:

> On 16 Декабрь 2003 18:17, info wrote:
> 
> > Полностью поддерживаю: у нас куча дектопов на рейзерах с
> > 2000-го года, перегружаются - понятное дело как (каждый день,
> > да не по одному разу), а иногда и жестко перегружаются -
> > сиречь вырубанием питания, если юзер - бревно. И за все это
> > время ни одной проблемы с потерей файлов никогда не было.
> Нет, проблема есть. Накрывается inittab (из-за hotplug?),
> XF86Config - неясно почему, ~/.../kmailrc - при вырубании после
> выхода из kmail, сама файловая система бывает портится до 
> необходимости fsck...
> Ядро >=2.4.20, reiserfs изначально 3.6

У меня ещё накрывался /etc/fstab. А жаль - довольно долго жил на
reiserfs и всем советовал, а недавно как попёрло... Системные
файлы не жалко, но у коллеги накрылся отлаживаемый php-скрипт на
разрекламированном мною reiserfs, на сервере накрылись два
jabber-ростера :(

Переполз на xfs. С интересом читаю fs-мнения.

Ядра - 2.4.20(22)-std-up(smp)

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] Re: XFS filesystem crash

[Serge Pavlovsky]

[-- Attachment #1: Type: text/plain, Size: 1498 bytes --]

В ?? 17.12.2003, в 14:13, Vitaly Ostanin пишет:
> On Wed, 17 Dec 2003 02:32:57 +0300
> Vitaly Lipatov <LAV@VL3143.spb.edu> wrote:
> 
> > On 16 Декабрь 2003 18:17, info wrote:
> > 
> > > Полностью поддерживаю: у нас куча дектопов на рейзерах с
> > > 2000-го года, перегружаются - понятное дело как (каждый день,
> > > да не по одному разу), а иногда и жестко перегружаются -
> > > сиречь вырубанием питания, если юзер - бревно. И за все это
> > > время ни одной проблемы с потерей файлов никогда не было.
> > Нет, проблема есть. Накрывается inittab (из-за hotplug?),
> > XF86Config - неясно почему, ~/.../kmailrc - при вырубании после
> > выхода из kmail, сама файловая система бывает портится до 
> > необходимости fsck...
> > Ядро >=2.4.20, reiserfs изначально 3.6
> 
> У меня ещё накрывался /etc/fstab. А жаль - довольно долго жил на
> reiserfs и всем советовал, а недавно как попёрло... Системные
> файлы не жалко, но у коллеги накрылся отлаживаемый php-скрипт на
> разрекламированном мною reiserfs, на сервере накрылись два
> jabber-ростера :(
> 
> Переполз на xfs. С интересом читаю fs-мнения.
> 
> Ядра - 2.4.20(22)-std-up(smp)
> 

у reiserfs при умирании может оказаться мусор в конце только что
записанного файла. у систем с журналированием данных этого конца просто
не будет. я сильно подозреваю, что винить надо софт. желающие могут
протестироват свою fs прилагаемой программой. не забудьте выключить кеш
винчестера. мне выключаться щас нельзя ;)


-- 
Serge Pavlovsky <pal@interexc.com>

[-- Attachment #2: a.cpp --]
[-- Type: text/x-c++, Size: 507 bytes --]

#include <unistd.h>
#include <stdio.h>
#include <fcntl.h>

static void stest ( ) {
	int f = open ( "/tmp/synctest2", O_WRONLY | O_CREAT, 0666 );
	if ( f < 0 )
		perror ( "fopen" );
	char s [ ] = "SYNC TEST\nSYNC TEST\n";
	if ( write ( f, s, sizeof ( s ) - 1 ) < 0 )
		perror ( "write" );
	if ( fsync ( f ) )
		perror ( "fsync" );
	if ( close ( f ) )
		perror ( "close" );
	if ( rename ( "/tmp/synctest2", "/tmp/synctest" ) )
		perror ( "rename" );
}
int main ( ) {
	while ( true )
		stest ( );
	return 0;
}

[-- Attachment #3: a.cpp --]
[-- Type: text/x-c++, Size: 507 bytes --]

#include <unistd.h>
#include <stdio.h>
#include <fcntl.h>

static void stest ( ) {
	int f = open ( "/tmp/synctest2", O_WRONLY | O_CREAT, 0666 );
	if ( f < 0 )
		perror ( "fopen" );
	char s [ ] = "SYNC TEST\nSYNC TEST\n";
	if ( write ( f, s, sizeof ( s ) - 1 ) < 0 )
		perror ( "write" );
	if ( fsync ( f ) )
		perror ( "fsync" );
	if ( close ( f ) )
		perror ( "close" );
	if ( rename ( "/tmp/synctest2", "/tmp/synctest" ) )
		perror ( "rename" );
}
int main ( ) {
	while ( true )
		stest ( );
	return 0;
}

[sisyphus] Re: XFS filesystem crash

[Epiphanov Sergei]

В сообщении от 16 Декабрь 2003 23:31 Денис Смирнов написал:

> Общий вывод:
>  - если данные очень дороги, то ext3 с data=journal это то, что вам надо
>  - если нужна ещё и высокая производительность, то XFS и _обязательно_
>    протестировать оборудование (хотя, на самом деле, тестировать надо
>    любую железку после покупки, и покупать, соответственно, там где её
>    если что согласятся обменять)
>  - если нужна высокая производительность на большом количестве файлов
>    небольшого размера (кэш прокси-сервера, например, /tmp, nntp-спул),
>    тогда ReiserFS оптимальный выбор.

Надо не забывать, что XFS, в отличие от ext2/ext3 и ReiserFS (не знаю, как 
ReiserFS сейчас), поддерживает объёмы файлов >2Гбайт. Поэтому даже если 
есть много маленьких файлов, но встречается хотя бы один ОЧЕНЬ большой 
файл, то вывод один - XFS. Кстати, ограничение на размер файла в 2Гбайта в 
ext2/ext3 действительно ОЧЕНЬ ОГРОМНАЯ ПРОБЛЕМА в моей организации, так 
как в работе меньше, чем за 1 день как раз набирается такой объём данных в 
одном файле. Постоянно приходится что-то резать. А XFS и ReiserFS нельзя 
использовать по некоторым требованиям (к сожалению, объяснение уж очень 
запутано).

-- 
С уважением, Епифанов Сергей

Re: [sisyphus] Re: XFS filesystem crash

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 393 bytes --]

* Epiphanov Sergei <serpiph@entek.ru> [031217 17:49]:
> Кстати, ограничение на размер файла в 2Гбайта в ext2/ext3
> действительно ОЧЕНЬ ОГРОМНАЯ ПРОБЛЕМА в моей организации, так 
Да нет там уже давно такого ограничения.

-- 
Regards, Sir Raorn.
-------------------
> Большинство программ можно отцепить от svgalib. А вот zgv придется
> удалить.
Долой svgalib! Долой zgv!
:)
		-- ldv in devel@

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[sisyphus] Re: XFS filesystem crash

[Anton V. Boyarshinov]

On Wed, 17 Dec 2003 17:45:55 +0300 Epiphanov Sergei
 wrote:

> Надо не забывать, что XFS, в отличие от ext2/ext3 и ReiserFS
> (не знаю, как ReiserFS сейчас), поддерживает объёмы файлов
> >2Гбайт.

ext2/ext3 тоже поддерживают и довольно давно.

> Поэтому даже если 
> есть много маленьких файлов, но встречается хотя бы один ОЧЕНЬ
> большой файл, то вывод один - XFS. Кстати, ограничение на
> размер файла в 2Гбайта в ext2/ext3 действительно ОЧЕНЬ ОГРОМНАЯ
> ПРОБЛЕМА в моей организации, так как в работе меньше, чем за 1
> день как раз набирается такой объём данных в одном файле.

Файлы >2Гбайт требуют специальной поддержки не только со стороны
fs но и со стороны программы. Например, для программы на С, если
не ошибаюсь:

#define _FILE_OFFSET_BITS 64
#define _LARGEFILE_SOURCE

Антон
-- 
mailto:boyarsh@mail.ru
mailto:boyarsh@ru.echo.fr
 17:52:00  up 25 days,  7:09, 10 users,  load average: 0.45,
0.16, 0.08

Re: [sisyphus] Re: XFS filesystem crash

[Led]

Epiphanov Sergei wrote:

>В сообщении от 16 Декабрь 2003 23:31 Денис Смирнов написал:
>
>  
>
>>Общий вывод:
>> - если данные очень дороги, то ext3 с data=journal это то, что вам надо
>> - если нужна ещё и высокая производительность, то XFS и _обязательно_
>>   протестировать оборудование (хотя, на самом деле, тестировать надо
>>   любую железку после покупки, и покупать, соответственно, там где её
>>   если что согласятся обменять)
>> - если нужна высокая производительность на большом количестве файлов
>>   небольшого размера (кэш прокси-сервера, например, /tmp, nntp-спул),
>>   тогда ReiserFS оптимальный выбор.
>>    
>>
>
>Надо не забывать, что XFS, в отличие от ext2/ext3 и ReiserFS (не знаю, как 
>ReiserFS сейчас), поддерживает объёмы файлов >2Гбайт. Поэтому даже если 
>есть много маленьких файлов, но встречается хотя бы один ОЧЕНЬ большой 
>файл, то вывод один - XFS. Кстати, ограничение на размер файла в 2Гбайта в 
>ext2/ext3 действительно ОЧЕНЬ ОГРОМНАЯ ПРОБЛЕМА в моей организации, так 
>как в работе меньше, чем за 1 день как раз набирается такой объём данных в 
>одном файле. Постоянно приходится что-то резать. А XFS и ReiserFS нельзя 
>использовать по некоторым требованиям (к сожалению, объяснение уж очень 
>запутано).
>
>  
>
В таком случае, откуда же у меня на reiserfs Soldier.vob размером 4,2Г?:)

Led.

Re: [sisyphus] Re: XFS filesystem crash

[Epiphanov Sergei]

В сообщении от 17 Декабрь 2003 17:54 Alexey I. Froloff написал:
> > Кстати, ограничение на размер файла в 2Гбайта в ext2/ext3
> > действительно ОЧЕНЬ ОГРОМНАЯ ПРОБЛЕМА в моей организации, так
>
> Да нет там уже давно такого ограничения.

Замечательно!!! А то именно эта причина (на Reiser не остался из-за 
отсутсвия тогда квот на дисковое пространство) меня побудила перейти 
где-то года полтора-два назад на XFS. Видно, я уже отстал от жизни в этом 
плане. :)))

-- 
С уважением, Епифанов Сергей

Re: [sisyphus] Re: XFS filesystem crash

[Alexey Morozov]

[-- Attachment #1: Type: text/plain, Size: 1271 bytes --]

On Wed, Dec 17, 2003 at 02:52:38AM +0300, Денис Смирнов wrote:
>  > Fortron (или Chieftec на худой конец).
> Любопытно, откуда данные? Цены на Fortron хоть и не маленькие, но вполне
> в разумном диапазоне, так что если по сравнению с InWin есть заметные
> преимущества -- мои приоритеты изменятся.
Насчет Fortron'а ничего не скажу, но у меня недавно InWin как раз и
умер ("пробой в транзисторах" типа бы). Люди, ремонтировавшие его
(сервис-отдел в комп. конторе), сказали, что-де это у нынешних
(примерно с год) InWin'ов - в порядке вещей, ремонтники не успевают эти
самые транзисторы докупать. На мой вопрос: а что стоит брать, сказали,
что ни у одного вендора сейчас нормальной статистики нет :-/

P.S. Ну, остается, конечно, вариант приобретения действительно
навороченного корпуса. У меня знакомец себе термалтейковский корпус
взял, за $300. Даже стандартного для меня в подобной ситуации вопроса:
"и шо ви с этого имеете?" не задашь, сразу все видно: внутри корпуса 7
пропеллеров,  четыре из них управляются при помощи выведенного в
верхний пятидюймовый слот приборчика с ЖК экраном и четырьмя ручками,
навроде авто-радио :-)). Ну и ко всему этому - прозрачная стенка,
"все дела \m/" :-). Надеюсь, термалтейк за такие деньги расстарается и
проверит набивку-то :-).


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] Re: XFS filesystem crash

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 692 bytes --]

On Wed, Dec 17, 2003 at 07:07:11PM +0300, Epiphanov Sergei wrote:
> В сообщении от 17 Декабрь 2003 17:54 Alexey I. Froloff написал:
> > > Кстати, ограничение на размер файла в 2Гбайта в ext2/ext3
> > > действительно ОЧЕНЬ ОГРОМНАЯ ПРОБЛЕМА в моей организации, так
> >
> > Да нет там уже давно такого ограничения.
> 
> Замечательно!!! А то именно эта причина (на Reiser не остался из-за 
> отсутсвия тогда квот на дисковое пространство) меня побудила перейти 
> где-то года полтора-два назад на XFS. Видно, я уже отстал от жизни в этом 
> плане. :)))

Вот только квоты на reiserfs как жили во внешнем патче, так и до сих пор
живут.  А на ext3 при работе с квотами обнаруживаются deadlock-и :(

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] Re: XFS filesystem crash

[Canis Cerberus]

В сообщении от 17 Декабрь 2003 19:08 Alexey Morozov написал(a):
> On Wed, Dec 17, 2003 at 02:52:38AM +0300, Денис Смирнов wrote:
> >  > Fortron (или Chieftec на худой конец).
> >
> > Любопытно, откуда данные? Цены на Fortron хоть и не маленькие, но вполне
> > в разумном диапазоне, так что если по сравнению с InWin есть заметные
> > преимущества -- мои приоритеты изменятся.
>
> Насчет Fortron'а ничего не скажу, но у меня недавно InWin как раз и
> умер ("пробой в транзисторах" типа бы). Люди, ремонтировавшие его
> (сервис-отдел в комп. конторе), сказали, что-де это у нынешних
> (примерно с год) InWin'ов - в порядке вещей, ремонтники не успевают эти
> самые транзисторы докупать. На мой вопрос: а что стоит брать, сказали,
> что ни у одного вендора сейчас нормальной статистики нет :-/
>
> P.S. Ну, остается, конечно, вариант приобретения действительно
> навороченного корпуса. У меня знакомец себе термалтейковский корпус
> взял, за $300. Даже стандартного для меня в подобной ситуации вопроса:
> "и шо ви с этого имеете?" не задашь, сразу все видно: внутри корпуса 7
> пропеллеров,  
А что, он на нем на работу летает? :))

-- 
Canis Cerberus
Magna est veritas et praevalebit !
A1000/KT333/256DDR/MatroxG450/Barracuda80Gb/Teac552/SBLive!/SJ3500c/DJ3820/SL45i
Санкт-Петербург

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Wed, Dec 17, 2003 at 10:24:47AM +0300, Epiphanov Sergei wrote:

 >> Проверьте подряд 2 sync'а. Дело в том, что первый sync начинает
 >> асинхронный сброс буферов (т.е. вываливается немедленно, но буферы ещё
 >> не сбросил). Второй sync завершается _только_ после сброса всех буферов.
 > А с какой стати он должен _так_ странно работать? Что за "разумные" 
 > действия? На то он и sync, чтобы всё сбросить на винт.

У разработчиков на этот счёт другое мнение. Если верить man 2 sync на моей
машине, то sync() только добавляет в очередь необходимые операции записи.
 
-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Wed, Dec 17, 2003 at 11:38:20AM +0200, Serge Pavlovsky wrote:

 > помоему там русским по белому сказано, что пока все не сбросит, не
 > вернется

Перечитайте man 2 sync, особое внимение уделив секции 'ОШИБКИ'.
 
-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Wed, Dec 17, 2003 at 10:43:51AM +0200, Michael Shigorin wrote:

 >>> Проверьте подряд 2 sync'а. Дело в том, что первый sync
 >>> начинает асинхронный сброс буферов (т.е. вываливается
 >>> немедленно, но буферы ещё не сбросил). Второй sync
 >>> завершается _только_ после сброса всех буферов.
 >> Так, я вдумчиво прочитал man sync, и понял что был не прав.
 >> Никакой информации о двойном sync для реального сброса данных я
 >> там не нашёл :(
 > Это старая юниксовая идиома, которая, кажется, в Немет
 > рассматривалась как соответствующая действительности все реже.

Ясно :( Что предлагается сейчас? Или сейчас это вообще не имеет решения?
 
-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Wed, Dec 17, 2003 at 05:45:55PM +0300, Epiphanov Sergei wrote:

 > Надо не забывать, что XFS, в отличие от ext2/ext3 и ReiserFS (не знаю, как 
 > ReiserFS сейчас), поддерживает объёмы файлов >2Гбайт. Поэтому даже если 
 > есть много маленьких файлов, но встречается хотя бы один ОЧЕНЬ большой 
 > файл, то вывод один - XFS. Кстати, ограничение на размер файла в 2Гбайта в 
 > ext2/ext3 действительно ОЧЕНЬ ОГРОМНАЯ ПРОБЛЕМА в моей организации, так 
 > как в работе меньше, чем за 1 день как раз набирается такой объём данных в 
 > одном файле. Постоянно приходится что-то резать. А XFS и ReiserFS нельзя 
 > использовать по некоторым требованиям (к сожалению, объяснение уж очень 
 > запутано).

Начиная с ядер 2.4.* ограничения в 2Gb на ext2/3 не существует.

Другое дело что xfs работает заметно корректнее ext2/3 на больших файлов,
особенно в случае доступа к одному диску несколькими пользователями.
 
-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Wed, Dec 17, 2003 at 07:22:05PM +0300, Sergey Vlasov wrote:

 > > > > Кстати, ограничение на размер файла в 2Гбайта в ext2/ext3
 > > > > действительно ОЧЕНЬ ОГРОМНАЯ ПРОБЛЕМА в моей организации, так
 > > > Да нет там уже давно такого ограничения.
 > > Замечательно!!! А то именно эта причина (на Reiser не остался из-за 
 > > отсутсвия тогда квот на дисковое пространство) меня побудила перейти 
 > > где-то года полтора-два назад на XFS. Видно, я уже отстал от жизни в этом 
 > > плане. :)))
 > Вот только квоты на reiserfs как жили во внешнем патче, так и до сих пор
 > живут.  А на ext3 при работе с квотами обнаруживаются deadlock-и :(

Подробнее про эти deadlock'и можно? Это весьма существенная информация.

-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Wed, Dec 17, 2003 at 05:59:50PM +0300, Anton V. Boyarshinov wrote:

 >> Поэтому даже если 
 >> есть много маленьких файлов, но встречается хотя бы один ОЧЕНЬ
 >> большой файл, то вывод один - XFS. Кстати, ограничение на
 >> размер файла в 2Гбайта в ext2/ext3 действительно ОЧЕНЬ ОГРОМНАЯ
 >> ПРОБЛЕМА в моей организации, так как в работе меньше, чем за 1
 >> день как раз набирается такой объём данных в одном файле.
 > Файлы >2Гбайт требуют специальной поддержки не только со стороны
 > fs но и со стороны программы. Например, для программы на С, если
 > не ошибаюсь:
 > #define _FILE_OFFSET_BITS 64
 > #define _LARGEFILE_SOURCE

Да, и ещё этот код должен быть написан вменяемым программистом (то есть
знающим, что off_t далеко не обязательно int), ну или использовать только
линейные чтение/запись (AFAIR).
 
-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Wed, Dec 17, 2003 at 10:47:20AM +0200, Michael Shigorin wrote:

 >>>> 1. есть хороший UPS (не стоит на нём экономить, лучше брать APC)
 >>> Если не экономить, а брать лучше -- то это Liebert скорее. :)
 >> Выше было сказано про "для дома" :) APC всё-таки на каждом углу продаются.
 > Домой -- APC?  (пользую некий Victron и все в полном ажуре)

У меня встречаются некоторые качества администратора -- а именно я ленивый
параноик :) Потратить 80$ на UPS домой, чтобы быть более-менее увереным в
электропитании я могу себе позволить.

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

 >>>> 2. хороший блок питания (например в корпусе от InWin)
 >>> Fortron (или Chieftec на худой конец).
 >> Любопытно, откуда данные? Цены на Fortron хоть и не маленькие,
 >> но вполне в разумном диапазоне, так что если по сравнению с
 >> InWin есть заметные преимущества -- мои приоритеты изменятся.
 > От сборщиков, которые не поленились собрать стенд и погонять
 > разные блоки.  Этот -- единственный, который не проваливался под
 > нагрузкой, соответствующей заявленным ТТХ (ВА по напряжениям,
 > суммарная мощность) и который реально переживает короткие между
 > любыми выходами.
 > Ну и пропеллеры.

Пропеллеры в смысле в этих блоках нормальные, или ты отдельно про них
напомнил?
 
-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Wed, Dec 17, 2003 at 10:08:54PM +0600, Alexey Morozov wrote:

 > P.S. Ну, остается, конечно, вариант приобретения действительно
 > навороченного корпуса. У меня знакомец себе термалтейковский корпус
 > взял, за $300. Даже стандартного для меня в подобной ситуации вопроса:
 > "и шо ви с этого имеете?" не задашь, сразу все видно: внутри корпуса 7
 > пропеллеров,  четыре из них управляются при помощи выведенного в
 > верхний пятидюймовый слот приборчика с ЖК экраном и четырьмя ручками,
 > навроде авто-радио :-)). Ну и ко всему этому - прозрачная стенка,
 > "все дела \m/" :-). Надеюсь, термалтейк за такие деньги расстарается и
 > проверит набивку-то :-).

Меня в этом корпусе просто убило то, что даже открывающаяся дверца
_металлическая_. Я был в шоке. Но ничего об их блоках питания я не знаю,
так что ни о чём, кроме хорошего охлаждения выводы делать не могу.

Кроме того мне однозначно не нравится ручное управление кулерами. IMHO это
должен делать отдельный контроллер с датчиками температуры.  Ручками разве
что температурный режим задаваться должен.

Дома всё-таки я либо работаю за компом, либо отдыхаю. И в том, и в другом
случае регулировать скорость вращения кулеров я не хочу. 

P.S. Куда-то мы от темы файловых систем в Linux ушли... :)

-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Wed, Dec 17, 2003 at 01:56:41PM +0200, Slava Garelin wrote:

 >>> А вот если не сложно развить мысль об изнеженности XFS? А то у меня
 >>> в последнее время ряд вопросов к ReiserFS, я на XFS поглядываю...
 >> Не то чтобы она была совсем уж изнеженой, просто она изначально была
 >> рассчитана на более другое железо и более другое использование.
 > ...
 > Большое спасибо за развернутый ответ!

Всегда пожалуйста. Кроме того на http://www.freesource.info/ лежит моя
статья на эту тему, она уже требует доводки, но всё ещё сохраняет
актуальности.
 
-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Wed, Dec 17, 2003 at 03:13:45PM +0300, Vitaly Ostanin wrote:

 > У меня ещё накрывался /etc/fstab. А жаль - довольно долго жил на
 > reiserfs и всем советовал, а недавно как попёрло... Системные
 > файлы не жалко, но у коллеги накрылся отлаживаемый php-скрипт на
 > разрекламированном мною reiserfs, на сервере накрылись два
 > jabber-ростера :(

Отлаживаемый скрипт стоило бы держать в CVS.

А вообще чем дальше, тем больше я склоняюсь к чему-то вроде NFS-сервера,
на котором пусть всё и лежит, а уж на этом сервере не пожалеть денег на
качественные комплектующие, и держать всё на RAID 5.

-- 
С уважением, Денис

http://freesource.info

Re: [sisyphus] Re: XFS filesystem crash

[Vitaly Lipatov]

On 17 Декабрь 2003 11:44, Michael Shigorin wrote:
> On Wed, Dec 17, 2003 at 02:28:35AM +0300, Vitaly Lipatov wrote:
> > > Кстати, в недавнем интервью Ганс сказал по крайней мере
> > > одну применимую к нам вещь -- fsck.reiserfs действительно
> > > стоит обновить.
> >
> > А у нас, насколько я понимаю, в пакете лежат очень старые
> > вещи и никто ими не занимается?
>
> Ага.  Заодно был бы рад отдать в надежные руки parted.
Мне? Нельзя! Я вам характеристику пришлю, я самый необязательный 
человек :)
А вообще я parted люблю, и всё собираюсь им заняться...
Я собирался пересобрать утилиты для reiserfs и заодно сделать 
пакет по образцу memtest86, который добавлял бы строку в меню, а 
в initrd для ядра был прописан sh и статически собранный 
reiserfsck, а то корневой раздел проверять замучаешься при 
проблемах...

-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! LaTeX! LyX!

Re: [sisyphus] Re: XFS filesystem crash

[Aleksey Avdeev]

Vitaly Lipatov пишет:
> On 17 Декабрь 2003 11:44, Michael Shigorin wrote:
> 
>>On Wed, Dec 17, 2003 at 02:28:35AM +0300, Vitaly Lipatov wrote:
>>
>>>>Кстати, в недавнем интервью Ганс сказал по крайней мере
>>>>одну применимую к нам вещь -- fsck.reiserfs действительно
>>>>стоит обновить.
>>>
>>>А у нас, насколько я понимаю, в пакете лежат очень старые
>>>вещи и никто ими не занимается?
>>
>>Ага.  Заодно был бы рад отдать в надежные руки parted.
> 
> Мне? Нельзя! Я вам характеристику пришлю, я самый необязательный 
> человек :)
> А вообще я parted люблю, и всё собираюсь им заняться...
> Я собирался пересобрать утилиты для reiserfs и заодно сделать 
> пакет по образцу memtest86, который добавлял бы строку в меню, а 
> в initrd для ядра был прописан sh и статически собранный 
> reiserfsck, а то корневой раздел проверять замучаешься при 
> проблемах...

   Эт вещь! Когда у меня в корне, на данной ФС, были проблемы 
(источника питания нехватало - пришлось CD удалить) - её здорово 
нехватало.

-- 

С уважением. Алексей.

Re: [sisyphus] Re: XFS filesystem crash

[info]

17 Декабрь 2003 23:17, Денис Смирнов написал:
> On Wed, Dec 17, 2003 at 03:13:45PM +0300, Vitaly Ostanin 
wrote:
>  > У меня ещё накрывался /etc/fstab. А жаль - довольно долго
>  > жил на reiserfs и всем советовал, а недавно как попёрло...
>  > Системные файлы не жалко, но у коллеги накрылся
>  > отлаживаемый php-скрипт на разрекламированном мною
>  > reiserfs, на сервере накрылись два jabber-ростера :(
>
> Отлаживаемый скрипт стоило бы держать в CVS.
>
> А вообще чем дальше, тем больше я склоняюсь к чему-то вроде
> NFS-сервера, на котором пусть всё и лежит, а уж на этом
> сервере не пожалеть денег на качественные комплектующие, и
> держать всё на RAID 5.

Поддерживаю. Именно так мы и работаем - с той только разницей, 
что на нашем сервере не RAID 5, а RAID 1, то бишь тупое 
зеркалирование. Причина проста. Дисковая память сейчас дешева, 
особо жмотиться смысла не имеет, а RAID 1 очень легко 
восстанавливается таже после тяжелого сбоя. Я проверял: даже 
если один из дисков RAID накрывается целиком, то монтируешь 
оставшийся как обычный раздел, и все данные - на месте.

Сейчас вот думаю перенести Home- директории пользователей туда 
же на NFS. Тогда, помимо прочего, каждый пользователь сможет 
работать с любой машины в сети. Когда-то давно, когда мы еще 
работали на Novell+Win3.11, у нас была именно такая 
конфигурация, и было очень удобно.

Георгий

Re: [sisyphus] Re: XFS filesystem crash

[Epiphanov Sergei]

В сообщении от 17 Декабрь 2003 19:22 Sergey Vlasov написал:

> Вот только квоты на reiserfs как жили во внешнем патче, так и до сих пор
> живут.  А на ext3 при работе с квотами обнаруживаются deadlock-и :(

Из огня да в полымя :))))

Интересно, а кто ещё что обнаружил странного в работе разных файловых 
систем? И что творится с JFS, SFS и т.д.? В Master2.0 (или 2.2?) было 
сказано, что JFS не рекомендуется пока для рабочих систем

[sisyphus] parted, reiserfs (was: XFS filesystem crash)

[Michael Shigorin]

On Thu, Dec 18, 2003 at 01:06:32AM +0300, Vitaly Lipatov wrote:
> > > > одну применимую к нам вещь -- fsck.reiserfs действительно
> > > > стоит обновить.
> > > А у нас, насколько я понимаю, в пакете лежат очень старые
> > > вещи и никто ими не занимается?
> > Ага.  Заодно был бы рад отдать в надежные руки parted.
> Мне? Нельзя! Я вам характеристику пришлю, я самый
> необязательный человек :)

Знаю-знаю-знаю-знаю, вот все за lyx наш не отблагодарю :)

> А вообще я parted люблю, и всё собираюсь им заняться...
> Я собирался пересобрать утилиты для reiserfs и заодно сделать
> пакет по образцу memtest86, который добавлял бы строку в меню,
> а в initrd для ядра был прописан sh и статически собранный
> reiserfsck, а то корневой раздел проверять замучаешься при
> проблемах...

Было бы замечательно.  С радостью передам все соображения по
теме, которыми делился umka@, когда отдавал мне эти (его тогда)
пакеты -- хотя, наверное, с Юрой лучше будет отдельно пообщаться.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[sisyphus] Re: XFS filesystem crash

[Michael Shigorin]

On Wed, Dec 17, 2003 at 11:04:26PM +0300, Денис Смирнов wrote:
>  >> Выше было сказано про "для дома" :) APC всё-таки на каждом углу продаются.
>  > Домой -- APC?  (пользую некий Victron и все в полном ажуре)
> У меня встречаются некоторые качества администратора -- а
> именно я ленивый параноик :) Потратить 80$ на UPS домой, чтобы
> быть более-менее увереным в электропитании я могу себе
> позволить.  Был бы я специалистом способным чётко оценить

А я у такого специалиста (доверенного) и забирал. ;-)

>  > Ну и пропеллеры.
> Пропеллеры в смысле в этих блоках нормальные, или ты отдельно
> про них напомнил?

И то и другое.

Не так давно, помимо force major с напругой в р-не колокейшнов,
имел радость зреть окончательно запылившийся и вставший пропеллер
на linux.kiev.ua, который в итоге жил на фронтальном hdd module...

Возвращаясь к теме линуксов: кто-нить что-нить поглядывающее на
сенсоры и истошно шлющее почту/sms-ки уже прикручивал?  Лень
изобретать велосипедд.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [sisyphus] Re: XFS filesystem crash

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 354 bytes --]

* Michael Shigorin <mike@osdn.org.ua> [031218 12:35]:
> Возвращаясь к теме линуксов: кто-нить что-нить поглядывающее на
> сенсоры и истошно шлющее почту/sms-ки уже прикручивал?  Лень
> изобретать велосипедд.
Nagios?

-- 
Regards, Sir Raorn.
-------------------
 Грамотное и безопасное программирование как-то плохо сочетается
с C/C++.
		-- vsl in devel@

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] Re: XFS filesystem crash

[Serge Pavlovsky]

В ?? 17.12.2003, в 21:52, Денис Смирнов пишет:
> On Wed, Dec 17, 2003 at 11:38:20AM +0200, Serge Pavlovsky wrote:
> 
>  > помоему там русским по белому сказано, что пока все не сбросит, не
>  > вернется
> 
> Перечитайте man 2 sync, особое внимение уделив секции 'ОШИБКИ'.

именно там это и сказано ;)
"начиная с версии 1.3.20, Linux действительно ожидает завершения записи"
 
-- 
Serge Pavlovsky <pal@interexc.com>

Re: [sisyphus] Re: XFS filesystem crash

[Serge Pavlovsky]

В ?? 17.12.2003, в 21:51, Денис Смирнов пишет:
> У разработчиков на этот счёт другое мнение. Если верить man 2 sync на моей
> машине, то sync() только добавляет в очередь необходимые операции записи.

это вы его не дочитали до конца ;) 
-- 
Serge Pavlovsky <pal@interexc.com>

[sisyphus] Re: XFS filesystem crash

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 339 bytes --]

On Thu, Dec 18, 2003 at 12:37:23PM +0300, Alexey I. Froloff wrote:
> > Возвращаясь к теме линуксов: кто-нить что-нить поглядывающее
> > на сенсоры и истошно шлющее почту/sms-ки уже прикручивал?
> Nagios?

Даже так?  Спасибо, пошел смотреть.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] Re: XFS filesystem crash

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 600 bytes --]

* Michael Shigorin <mike@osdn.org.ua> [031218 13:00]:
> > > Возвращаясь к теме линуксов: кто-нить что-нить поглядывающее
> > > на сенсоры и истошно шлющее почту/sms-ки уже прикручивал?
> > Nagios?
> Даже так?  Спасибо, пошел смотреть.
Er... Nagios умеет пинать поглядывалку на сенсоры и в зависимости
от результатов пинать почто/sms-посылалку.

-- 
Regards, Sir Raorn.
-------------------
> Поскольку php-4.1.2-alt4 в сегодняшнем Сизифе оказался не полным,
> пользователям php рекомендуется подождать завтрашнего Сизифа.
Могу только повторить сказанное, с заменой alt4 на alt5.
		-- ldv in sisyphus@

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] Re: XFS filesystem crash

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 1043 bytes --]

On Wed, Dec 17, 2003 at 10:58:43PM +0300, Денис Смирнов wrote:
> On Wed, Dec 17, 2003 at 07:22:05PM +0300, Sergey Vlasov wrote:
> 
>  > > > > Кстати, ограничение на размер файла в 2Гбайта в ext2/ext3
>  > > > > действительно ОЧЕНЬ ОГРОМНАЯ ПРОБЛЕМА в моей организации, так
>  > > > Да нет там уже давно такого ограничения.
>  > > Замечательно!!! А то именно эта причина (на Reiser не остался из-за 
>  > > отсутсвия тогда квот на дисковое пространство) меня побудила перейти 
>  > > где-то года полтора-два назад на XFS. Видно, я уже отстал от жизни в этом 
>  > > плане. :)))
>  > Вот только квоты на reiserfs как жили во внешнем патче, так и до сих пор
>  > живут.  А на ext3 при работе с квотами обнаруживаются deadlock-и :(
> 
> Подробнее про эти deadlock'и можно? Это весьма существенная информация.

Вот последний:

http://lkml.org/lkml/2003/10/27/3

Странно, мне казалось, что я положил этот патч в kernel-fix-fs, но сейчас
его там нет...  Хотя и реакции на этот патч тоже не было - не совсем
понятно, исправил он эту проблему или нет.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[sisyphus] Re: XFS filesystem crash

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 511 bytes --]

On Thu, Dec 18, 2003 at 01:02:40PM +0300, Alexey I. Froloff wrote:
> > > > Возвращаясь к теме линуксов: кто-нить что-нить
> > > > поглядывающее на сенсоры и истошно шлющее почту/sms-ки
> > > > уже прикручивал?
> > > Nagios?
> > Даже так?  Спасибо, пошел смотреть.
> Er... Nagios умеет пинать поглядывалку на сенсоры и в
> зависимости от результатов пинать почто/sms-посылалку.

А от бритвы как уворачивается? ;-)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] Re: XFS filesystem crash

[Roman Savelyev]

> Вот только квоты на reiserfs как жили во внешнем патче, так и до сих пор
> живут.  А на ext3 при работе с квотами обнаруживаются deadlock-и :(
А, фигня. Reiser4 на подлёте.

[sisyphus] Re: XFS filesystem crash

[Michael Shigorin]

On Thu, Dec 18, 2003 at 03:00:29PM +0300, Roman Savelyev wrote:
> > Вот только квоты на reiserfs как жили во внешнем патче, так и
> > до сих пор живут.  А на ext3 при работе с квотами
> > обнаруживаются deadlock-и :(
> А, фигня. Reiser4 на подлёте.

В конце сентября от авторитетного по теме человека прозвучало
"пользовать для данных НЕ РЕКОМЕНДУЕМ (пока)".

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[sisyphus] Re: [JT] XFS filesystem crash

[Vitaly Ostanin]

[-- Attachment #1: Type: text/plain, Size: 1088 bytes --]

On Wed, 17 Dec 2003 23:17:46 +0300
Денис Смирнов <mithraen@freesource.info> wrote:

> On Wed, Dec 17, 2003 at 03:13:45PM +0300, Vitaly Ostanin wrote:
> 
>  > У меня ещё накрывался /etc/fstab. А жаль - довольно долго
>  > жил на reiserfs и всем советовал, а недавно как попёрло...
>  > Системные файлы не жалко, но у коллеги накрылся отлаживаемый
>  > php-скрипт на разрекламированном мною reiserfs, на сервере
>  > накрылись два jabber-ростера :(
> 
> Отлаживаемый скрипт стоило бы держать в CVS.

:)))) Сразу после обнаружения мусора коллега был пропарен на тему
cvs :)

> А вообще чем дальше, тем больше я склоняюсь к чему-то вроде
> NFS-сервера, на котором пусть всё и лежит, а уж на этом сервере
> не пожалеть денег на качественные комплектующие, и держать всё
> на RAID 5.

Не пожалели. Mylex AcceleRAID 170. Аппаратный scsi raid 5, вместе
с дисками обошёлся за $1000. Лежит сейчас в тумбочке, ждёт своей
очереди на разбирательства :(

Да, теперь я уже знаю про softraid :)

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] Re: XFS filesystem crash

[Roman Savelyev]

В Чтв, 18.12.2003, в 16:11, Michael Shigorin пишет:
> В конце сентября от авторитетного по теме человека прозвучало
> "пользовать для данных НЕ РЕКОМЕНДУЕМ (пока)".
Разумеется. Оно в настоящее время в стадии финального тестирования.

Re: [sisyphus] Re: XFS filesystem crash

[Peter S. Voronov]

Hello Michael,

 18 декабря 2003 г., you wrote:

MS> On Thu, Dec 18, 2003 at 03:00:29PM +0300, Roman Savelyev wrote:
>> > Вот только квоты на reiserfs как жили во внешнем патче, так и
>> > до сих пор живут.  А на ext3 при работе с квотами
>> > обнаруживаются deadlock-и :(
>> А, фигня. Reiser4 на подлёте.

MS> В конце сентября от авторитетного по теме человека прозвучало
MS> "пользовать для данных НЕ РЕКОМЕНДУЕМ (пока)".

А возникает интересный (вредный) вопрос - а для чего рекомендуем, если
не для данных ??????????????


-- 
Best regards,
 Peter S. Voronov
 

Re: [sisyphus] Re: XFS filesystem crash

[Roman Savelyev]

В Чтв, 18.12.2003, в 18:34, Peter S. Voronov пишет:
> А возникает интересный (вредный) вопрос - а для чего рекомендуем, если
> не для данных ??????????????
Для финального тестирования :)

[sisyphus] Re: [JT] XFS filesystem crash

[Michael Shigorin]

On Thu, Dec 18, 2003 at 04:38:07PM +0300, Vitaly Ostanin wrote:
> Не пожалели. Mylex AcceleRAID 170. Аппаратный scsi raid 5,
> вместе с дисками обошёлся за $1000. Лежит сейчас в тумбочке,
> ждёт своей очереди на разбирательства :(

А что -- не разбирается??

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Thu, Dec 18, 2003 at 11:45:53AM +0200, Serge Pavlovsky wrote:

 >>> помоему там русским по белому сказано, что пока все не сбросит, не
 >>> вернется
 >> Перечитайте man 2 sync, особое внимение уделив секции 'ОШИБКИ'.
 > именно там это и сказано ;)
 > "начиная с версии 1.3.20, Linux действительно ожидает завершения записи"

Это документ, относящийся (если верить тому, что в нём же написаный) к
ядру 1.3.88. В те времена XFS ещё не существовало. XFS, пользуясь тем, что
стандарт это позволяет, реализует сие по-другому, насколько мне это
известно.

Я не умею пользоваться средствами отладки ядра (если мне кто-нибудь
расскажет каким образом такие вещи делаются, я буду очень рад), поэтому не
могу посмотреть как это происходит в реальности на разных файловых
системах.

-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Wed, Dec 17, 2003 at 09:49:18PM +0300, Canis Cerberus wrote:

 > А что, он на нем на работу летает? :))

Хрен его знает :) Я бы за такие бабки предпочёл бы систему жидкостного
охлаждения -- хоть шумит меньше :)
 
-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Thu, Dec 18, 2003 at 01:12:55PM +0300, Sergey Vlasov wrote:

 > Вот последний:
 > http://lkml.org/lkml/2003/10/27/3
 > Странно, мне казалось, что я положил этот патч в kernel-fix-fs, но сейчас
 > его там нет...  Хотя и реакции на этот патч тоже не было - не совсем
 > понятно, исправил он эту проблему или нет.

:-(

-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Thu, Dec 18, 2003 at 12:19:19PM +0300, Epiphanov Sergei wrote:

 > Интересно, а кто ещё что обнаружил странного в работе разных файловых 
 > систем? И что творится с JFS, SFS и т.д.? В Master2.0 (или 2.2?) было 
 > сказано, что JFS не рекомендуется пока для рабочих систем

Если кратко -- в реализации JFS для Linux я пока не вижу ни одного
преимущества перед остальными имеющимися FS. Сейчас основой выбор это
ext3/xfs/reiserfs, и, соответственно, между разными соотношениями
скорость/надёжность на разных типах файлов и режимах эксплуатации. Всё
остальное нужно либо для совместимости (HPFS, NTFS, FAT, Minix), либо для
специальных задач (cramfs), либо непонятно для чего (JFS). Разумеется
IMHO.
 
-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Thu, Dec 18, 2003 at 11:56:59AM +0300, info wrote:

 > Поддерживаю. Именно так мы и работаем - с той только разницей, 
 > что на нашем сервере не RAID 5, а RAID 1, то бишь тупое 
 > зеркалирование. Причина проста. Дисковая память сейчас дешева, 
 > особо жмотиться смысла не имеет, а RAID 1 очень легко 
 > восстанавливается таже после тяжелого сбоя. Я проверял: даже 
 > если один из дисков RAID накрывается целиком, то монтируешь 
 > оставшийся как обычный раздел, и все данные - на месте.

Когда современный диск обнаруживает badblock, то он делает отображение на
один из резервных, который оказывается _обнулённым_. Как на такое
реагирует RAID 1? Не окажется ли, что он именно его и скопирует на другой?
В случае RAID 5, насколько я понимаю, эта ситуация обработается вполне
корректно. RAID 1, также насколько я понмаю, пригоден только для спасения
от ситуаций вида "хард умер".

-- 
С уважением, Денис

http://freesource.info

[sisyphus] ReiserFS

[Денис Смирнов]

On Thu, Dec 18, 2003 at 03:00:29PM +0300, Roman Savelyev wrote:

 >> Вот только квоты на reiserfs как жили во внешнем патче, так и до сих пор
 >> живут.  А на ext3 при работе с квотами обнаруживаются deadlock-и :(
 > А, фигня. Reiser4 на подлёте.

По поводу Reiser4 вопросы:

1. Он включен в 2.6?
2. Где можно прочитать описание всех изменений, по сравнению с ReiserFS 4?

-- 
С уважением, Денис

http://freesource.info

Re: [sisyphus] Re: XFS filesystem crash

[Maxim Tyurin]

[-- Attachment #1: Type: text/plain, Size: 646 bytes --]

On Thu, Dec 18, 2003 at 08:56:21PM +0300, Денис Смирнов wrote:
> Если кратко -- в реализации JFS для Linux я пока не вижу ни одного
> преимущества перед остальными имеющимися FS. Сейчас основой выбор это
> ext3/xfs/reiserfs, и, соответственно, между разными соотношениями
> скорость/надёжность на разных типах файлов и режимах эксплуатации. Всё
> остальное нужно либо для совместимости (HPFS, NTFS, FAT, Minix), либо для
> специальных задач (cramfs), либо непонятно для чего (JFS). Разумеется
> IMHO.

У нее загрузка CPU самая маленькая. Хотя я тоже ей применения не нашел ;)
-- 

With Best Regards, Maxim Tyurin
JID:	MrKooll@jabber.pibhe.com
			

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] Re: XFS filesystem crash

[Sergey]

On Wednesday 17 December 2003 20:07, Epiphanov Sergei wrote:

> > Да нет там уже давно такого ограничения.
> 
> где-то года полтора-два назад на XFS. Видно, я уже отстал от жизни в этом 
> плане. :)))

Ограничение в 2 Гб на ext2 было снято где-то в послених 2.3. То есть, у 
ядер 2.4 его не было изначально. ;-)

-- 
С уважением, Сергей
a_s_y@sama.ru

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Thu, Dec 18, 2003 at 04:38:07PM +0300, Vitaly Ostanin wrote:

 >> А вообще чем дальше, тем больше я склоняюсь к чему-то вроде
 >> NFS-сервера, на котором пусть всё и лежит, а уж на этом сервере
 >> не пожалеть денег на качественные комплектующие, и держать всё
 >> на RAID 5.
 > Не пожалели. Mylex AcceleRAID 170. Аппаратный scsi raid 5, вместе
 > с дисками обошёлся за $1000. Лежит сейчас в тумбочке, ждёт своей
 > очереди на разбирательства :(
 > Да, теперь я уже знаю про softraid :)

Наслушавшись негативных отзывов о разных RAID'ах я уже для себя решил
использовать только Software RAID. По крайней мере он рано или поздно
будет работать действительно _хорошо_.

-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Thu, Dec 18, 2003 at 03:11:02PM +0200, Michael Shigorin wrote:

 >>> Вот только квоты на reiserfs как жили во внешнем патче, так и
 >>> до сих пор живут.  А на ext3 при работе с квотами
 >>> обнаруживаются deadlock-и :(
 >> А, фигня. Reiser4 на подлёте.
 > В конце сентября от авторитетного по теме человека прозвучало
 > "пользовать для данных НЕ РЕКОМЕНДУЕМ (пока)".

Рейзер будет пригоден к использованию, скорее всего, после того как годик
побудет файловой системой по-умолчанию для одного из распространённых
дистрибутивов (например Fedora).
 
-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Thu, Dec 18, 2003 at 05:34:42PM +0200, Peter S. Voronov wrote:

 > А возникает интересный (вредный) вопрос - а для чего рекомендуем, если
 > не для данных ??????????????

В настоящий момент файловой системы для /tmp и /var/cache/squid лучше чем
ReiserFS не существует в природе :)
 
-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: XFS filesystem crash

[Michael Shigorin]

On Thu, Dec 18, 2003 at 10:35:16PM +0300, Денис Смирнов wrote:
>  >> А, фигня. Reiser4 на подлёте.
>  > В конце сентября от авторитетного по теме человека прозвучало
>  > "пользовать для данных НЕ РЕКОМЕНДУЕМ (пока)".
> Рейзер будет пригоден к использованию, скорее всего, после того
> как годик побудет файловой системой по-умолчанию для одного из
> распространённых дистрибутивов (например Fedora).

Ха-ха два раза.  Нет, не для федоры.  Скорее после того, как SuSE
на rfs4 перейдет.

PS: OT?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [sisyphus] Re: XFS filesystem crash

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 1472 bytes --]

On Thu, Dec 18, 2003 at 09:08:16PM +0300, Денис Смирнов wrote:
> On Thu, Dec 18, 2003 at 11:56:59AM +0300, info wrote:
> 
>  > Поддерживаю. Именно так мы и работаем - с той только разницей, 
>  > что на нашем сервере не RAID 5, а RAID 1, то бишь тупое 
>  > зеркалирование. Причина проста. Дисковая память сейчас дешева, 
>  > особо жмотиться смысла не имеет, а RAID 1 очень легко 
>  > восстанавливается таже после тяжелого сбоя. Я проверял: даже 
>  > если один из дисков RAID накрывается целиком, то монтируешь 
>  > оставшийся как обычный раздел, и все данные - на месте.
> 
> Когда современный диск обнаруживает badblock, то он делает отображение на
> один из резервных, который оказывается _обнулённым_. Как на такое
> реагирует RAID 1? Не окажется ли, что он именно его и скопирует на другой?
> В случае RAID 5, насколько я понимаю, эта ситуация обработается вполне
> корректно. RAID 1, также насколько я понмаю, пригоден только для спасения
> от ситуаций вида "хард умер".

Правильный диск не должен так себя вести (это некоторое время назад
обсуждалось в lkml).  При чтении ничего переназначаться не будет.  А
вот при записи в этот сектор действительно должно произойти
переназначение.

Экспериментально проверялось на нескольких старых дисках Seagate -
завершения работы badblocks на них так и не дождались, а вот после
badblocks -w ни одного плохого сектора обнаружено не было (а
информация SMART показала наличие большого количества переназначенных
секторов).

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] ReiserFS

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 657 bytes --]

On Thu, Dec 18, 2003 at 09:23:23PM +0300, Денис Смирнов wrote:
> On Thu, Dec 18, 2003 at 03:00:29PM +0300, Roman Savelyev wrote:
> 
>  >> Вот только квоты на reiserfs как жили во внешнем патче, так и до сих пор
>  >> живут.  А на ext3 при работе с квотами обнаруживаются deadlock-и :(
>  > А, фигня. Reiser4 на подлёте.
> 
> По поводу Reiser4 вопросы:
> 
> 1. Он включен в 2.6?

Ещё нет (поскольку сами авторы признают, что эта версия ещё не готова
к реальному использованию - пока что она предлагается только для
тестирования добровольцами).

> 2. Где можно прочитать описание всех изменений, по сравнению с ReiserFS 4?

Очевидно, http://www.namesys.com .

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] Re: XFS filesystem crash

[Kylik Semuon]

В Чтв, 18.12.2003, в 21:32, Денис Смирнов написал:
> On Thu, Dec 18, 2003 at 04:38:07PM +0300, Vitaly Ostanin wrote:
> 
>  >> А вообще чем дальше, тем больше я склоняюсь к чему-то вроде
>  >> NFS-сервера, на котором пусть всё и лежит, а уж на этом сервере
>  >> не пожалеть денег на качественные комплектующие, и держать всё
>  >> на RAID 5.
>  > Не пожалели. Mylex AcceleRAID 170. Аппаратный scsi raid 5, вместе
>  > с дисками обошёлся за $1000. Лежит сейчас в тумбочке, ждёт своей
>  > очереди на разбирательства :(
>  > Да, теперь я уже знаю про softraid :)
> 
> Наслушавшись негативных отзывов о разных RAID'ах я уже для себя решил
> использовать только Software RAID. По крайней мере он рано или поздно
> будет работать действительно _хорошо_.

Ну и зря
Adaptek 2200 (2 канала, 64М на борту) - заводится из коробки M2.2
8 - НДД (2 зеркала + 5-ый). За пол-года ни одной проблемы.
Счас там W2K (PDC). Второй начал умирать (материнка), так срочно
пришлось переселять PDC.

Второй Mylex AcceleRAID 352 (правда под виндами) 2 - года нет проблем.

PS. BadBlock - проблема HDD и снаружи не видна, а если видна, то срочно
надо его (винт) менять.

С уважением, Семен.

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Thu, Dec 18, 2003 at 08:45:06PM +0200, Maxim Tyurin wrote:

 >> Если кратко -- в реализации JFS для Linux я пока не вижу ни одного
 >> преимущества перед остальными имеющимися FS. Сейчас основой выбор это
 >> ext3/xfs/reiserfs, и, соответственно, между разными соотношениями
 >> скорость/надёжность на разных типах файлов и режимах эксплуатации. Всё
 >> остальное нужно либо для совместимости (HPFS, NTFS, FAT, Minix), либо для
 >> специальных задач (cramfs), либо непонятно для чего (JFS). Разумеется
 >> IMHO.
 > У нее загрузка CPU самая маленькая.

:-))))))

Вот что-что, а чтобы узким горлышком на _сервере_ был процессор, а не
диски... Не видел такого. У меня обычно всё упирается в диски, иногда ещё
в память. Процессор если ставить оптимальный по цена/производительность на
текущий момент, обычно оказывается перегружен последним, да и стоимость
его апгрейда и рядом не стояла со стоимостью дисков.
 
 > Хотя я тоже ей применения не нашел ;)

:)

-- 
С уважением, Денис

http://freesource.info

Re: [sisyphus] Re: XFS filesystem crash

[Sergey V. Degtyaryov]

Денис Смирнов пишет:
> On Thu, Dec 18, 2003 at 03:11:02PM +0200, Michael Shigorin wrote:
> 
>  >>> Вот только квоты на reiserfs как жили во внешнем патче, так и
>  >>> до сих пор живут.  А на ext3 при работе с квотами
>  >>> обнаруживаются deadlock-и :(
>  >> А, фигня. Reiser4 на подлёте.
>  > В конце сентября от авторитетного по теме человека прозвучало
>  > "пользовать для данных НЕ РЕКОМЕНДУЕМ (пока)".
> 
> Рейзер будет пригоден к использованию, скорее всего, после того как годик
> побудет файловой системой по-умолчанию для одного из распространённых
> дистрибутивов (например Fedora).
>  

А как же SuSE?

--
Сергей Дегтярев

[sisyphus] Re: iserFS

[Денис Смирнов]

On Thu, Dec 18, 2003 at 11:16:33PM +0300, Sergey Vlasov wrote:

 >>>> Вот только квоты на reiserfs как жили во внешнем патче, так и до сих пор
 >>>> живут.  А на ext3 при работе с квотами обнаруживаются deadlock-и :(
 >>> А, фигня. Reiser4 на подлёте.
 >> По поводу Reiser4 вопросы:
 >> 1. Он включен в 2.6?
 > Ещё нет (поскольку сами авторы признают, что эта версия ещё не готова
 > к реальному использованию - пока что она предлагается только для
 > тестирования добровольцами).

Жаль, значит полноценного тестирования на кошках она не пройдёт, и не
скоро будет по настоящему юзабельной :-(
 
 >> 2. Где можно прочитать описание всех изменений, по сравнению с ReiserFS 4?
 > Очевидно, http://www.namesys.com .

Ok, спасибо.

-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Thu, Dec 18, 2003 at 09:57:31PM +0200, Michael Shigorin wrote:

 >>>> А, фигня. Reiser4 на подлёте.
 >>> В конце сентября от авторитетного по теме человека прозвучало
 >>> "пользовать для данных НЕ РЕКОМЕНДУЕМ (пока)".
 >> Рейзер будет пригоден к использованию, скорее всего, после того
 >> как годик побудет файловой системой по-умолчанию для одного из
 >> распространённых дистрибутивов (например Fedora).
 > Ха-ха два раза.  Нет, не для федоры.  Скорее после того, как SuSE
 > на rfs4 перейдет.

Fedora массовее, за год тестирования на федоре пионеры, её использующиеся,
обматерят каждый глюк :) После этого на него и перейдёт SuSE, и можно
будет юзать :)
 
 > PS: OT?

Видимо да. Закрываем эту ветку.
 
-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Thu, Dec 18, 2003 at 11:11:06PM +0300, Sergey Vlasov wrote:

 > Правильный диск не должен так себя вести (это некоторое время назад
 > обсуждалось в lkml).  При чтении ничего переназначаться не будет.  А
 > вот при записи в этот сектор действительно должно произойти
 > переназначение.

Как поведёт себя диск, если не сможет _прочитать_ данные из сектора?
Не сходятся у него контрольные суммы. Как он себя поведёт?
 
 > Экспериментально проверялось на нескольких старых дисках Seagate -
 > завершения работы badblocks на них так и не дождались, а вот после
 > badblocks -w ни одного плохого сектора обнаружено не было (а
 > информация SMART показала наличие большого количества переназначенных
 > секторов).

Ясно. Хотя без официальных данных от производителей я бы не стал на это
полагаться... По крайней мере для нынешнего IDE барахла.

-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Thu, Dec 18, 2003 at 10:47:04PM +0200, Kylik Semuon wrote:

 >>>> А вообще чем дальше, тем больше я склоняюсь к чему-то вроде
 >>>> NFS-сервера, на котором пусть всё и лежит, а уж на этом сервере
 >>>> не пожалеть денег на качественные комплектующие, и держать всё
 >>>> на RAID 5.
 >>> Не пожалели. Mylex AcceleRAID 170. Аппаратный scsi raid 5, вместе
 >>> с дисками обошёлся за $1000. Лежит сейчас в тумбочке, ждёт своей
 >>> очереди на разбирательства :(
 >>> Да, теперь я уже знаю про softraid :)
 >> Наслушавшись негативных отзывов о разных RAID'ах я уже для себя решил
 >> использовать только Software RAID. По крайней мере он рано или поздно
 >> будет работать действительно _хорошо_.
 > Ну и зря
 > Adaptek 2200 (2 канала, 64М на борту) - заводится из коробки M2.2
 > 8 - НДД (2 зеркала + 5-ый). За пол-года ни одной проблемы.
 > Счас там W2K (PDC). Второй начал умирать (материнка), так срочно
 > пришлось переселять PDC.
 > Второй Mylex AcceleRAID 352 (правда под виндами) 2 - года нет проблем.

Сколько за это время было реальных выходов из строя HDD?
 
 > PS. BadBlock - проблема HDD и снаружи не видна, а если видна, то срочно
 > надо его (винт) менять.

BadBlock == потеря данных в одном блоке, причём, на современных хардах,
незаметная для приложения (кроме как по потере этих самых данных). Вещь
достаточно редкая, но встречающаяся, увы.
 
-- 
С уважением, Денис

http://freesource.info

Re: [sisyphus] Re: XFS filesystem crash

[Дмитрий Герасимов]

Денис Смирнов wrote:

>On Wed, Dec 17, 2003 at 09:49:18PM +0300, Canis Cerberus wrote:
>
> > А что, он на нем на работу летает? :))
>
>Хрен его знает :) Я бы за такие бабки предпочёл бы систему жидкостного
>охлаждения -- хоть шумит меньше :)
> 
>  
>
Termaltake Xaser II - ураганная вещь. :) кстати шумит не очень сильно. Я 
бы даже сказал почти не шумит. Правда все его вентиляторы я никогда не 
включал, зато БП там очень хороший.
сорри за оффтоп.

Re: [sisyphus] XFS filesystem crash

[info]

17 Декабрь 2003 02:32, Vitaly Lipatov написал:
> On 16 Декабрь 2003 18:17, info wrote:
> > Полностью поддерживаю: у нас куча дектопов на рейзерах с
> > 2000-го года, перегружаются - понятное дело как (каждый
> > день, да не по одному разу), а иногда и жестко
> > перегружаются - сиречь вырубанием питания, если юзер -
> > бревно. И за все это время ни одной проблемы с потерей
> > файлов никогда не было.
>
> Нет, проблема есть. Накрывается inittab (из-за hotplug?),
> XF86Config - неясно почему, ~/.../kmailrc - при вырубании
> после выхода из kmail, сама файловая система бывает портится
> до необходимости fsck...
> Ядро >=2.4.20, reiserfs изначально 3.6

Виталий, у меня из головы не шли Ваши накрытия рейзера - потому 
как сам на нем сижу... Вот такой вопрос - а ядро у Вас какое? 
Оригинальное c kernel.org или нет? Какие патчи? И, главное, 
если ли среди них low-latency sheduler? Дело в том, что эта 
штука дописывает свои куски в коды всех основных файловых 
систем (ext2/ext3/reiser); причем на ядре 2.4.23 патч у меня в 
двух местах  провалился, и не где-нибудь, а на  fs/inode.c и 
fs/buffer.c. А занимается она, как известно, тем, что 
целенаправленно тормозит в том числе и работу с файловой 
системой ради качества звука. Не в ней ли дело?

Георгий 

Re: [sisyphus] Re: XFS filesystem crash

[info]

18 Декабрь 2003 21:08, Денис Смирнов написал:
> On Thu, Dec 18, 2003 at 11:56:59AM +0300, info wrote:
>  > Поддерживаю. Именно так мы и работаем - с той только
>  > разницей, что на нашем сервере не RAID 5, а RAID 1, то
>  > бишь тупое зеркалирование. Причина проста. Дисковая память
>  > сейчас дешева, особо жмотиться смысла не имеет, а RAID 1
>  > очень легко восстанавливается таже после тяжелого сбоя. Я
>  > проверял: даже если один из дисков RAID накрывается
>  > целиком, то монтируешь оставшийся как обычный раздел, и
>  > все данные - на месте.
>
> Когда современный диск обнаруживает badblock, то он делает
> отображение на один из резервных, который оказывается
> _обнулённым_. Как на такое реагирует RAID 1? Не окажется ли,
> что он именно его и скопирует на другой? В случае RAID 5,
> насколько я понимаю, эта ситуация обработается вполне
> корректно. RAID 1, также насколько я понмаю, пригоден только
> для спасения от ситуаций вида "хард умер".

Когда я решал, какой вид RAID ставить, то прежде всего поискал в 
инете реальные истории тех людей, которые его восстанавливали 
после сбоев. Счас уже не помню где, но была пара леденящих душу 
историй, как RAID 5 после тяжелого сбоя восстановить так и не 
сумели. 

Насколько я понимаю, RAID 5 хорош для преодоления относительно 
легких сбоев - с которыми он справляется без вашего участия. 
Его идеология довольно старая, когда дисковая память была ну 
очень дорогой, и делать даже однократное (не говоря уже о 
двух-трехкратном) зеркалирование казалось верхом 
расточительства. Так что RAID 5 есть компромисс - некоторое 
повышение надежности за счет не сильного перерасхода дискового 
пространства. 

Что же касается RAID 1, то, насколько я понимаю, в описываемой 
Вами ситуации, когда один диск отражает badblock на один из 
своих резервных блоков, то ровно то же самое делает и второй 
диск - хотя у него этот блок и не bad. Может, я не прав. Но 
RAID 1 я тестировал полгода на в усмерть убитом SCSI 1997-го 
года выпуска c морем badblock-ов, забивал его под завязку 
большими, но не слишком ценными файлами (да простят меня 
ALT-овцы - это были RPM-ы сизифуса), и все работало нормально 
жо тех пор, пока сказя окончательно не сдохла. Причем была пара 
ситуаций, когда приходилось делать --rebuild-tree - и даже 
после этого ничего не пропадало, все восстанавливалось.

Ну, а если хотите совсем уж надежности - сделайте два RAID 5 
массива, а потом зазеркалируйте их как RAID 1.

Георгий

Re: [sisyphus] Re: XFS filesystem crash

[Roman Savelyev]

В Чтв, 18.12.2003, в 20:56, Денис Смирнов пишет:
> Если кратко -- в реализации JFS для Linux я пока не вижу ни одного
> преимущества перед остальными имеющимися FS.
Оно надо в основном IBM-у, для совместимости носителей с AIX.
> специальных задач (cramfs), либо непонятно для чего (JFS). Разумеется
> IMHO.
JFFS2 - тоже очень и очень хороша для своих задачек.

Re: [sisyphus] Re: XFS filesystem crash

[Roman Savelyev]

В Чтв, 18.12.2003, в 23:51, Денис Смирнов пишет:
> Вот что-что, а чтобы узким горлышком на _сервере_ был процессор, а не
> диски... Не видел такого.
Показать? Если это файл-помойка, то её и сервером-то считать язык не
поворачивается, еслиже это сервер приложений, то....

Re: [sisyphus] ReiserFS

[Roman Savelyev]

В Чтв, 18.12.2003, в 21:23, Денис Смирнов пишет:
> 1. Он включен в 2.6?
Ещё нет. Тестирование ещё не завершено.
> 2. Где можно прочитать описание всех изменений, по сравнению с ReiserFS 4?
http://www.namesys.com

Re: [sisyphus] Re: XFS filesystem crash

[Roman Savelyev]

В Чтв, 18.12.2003, в 22:57, Michael Shigorin пишет:
> Ха-ха два раза.  Нет, не для федоры.  Скорее после того, как SuSE
> на rfs4 перейдет.
Вообще-то "четвёрка" делается по заказу DARPA :)

[sisyphus] Re: XFS filesystem crash

[Michael Shigorin]

On Fri, Dec 19, 2003 at 11:17:57AM +0300, info wrote:
> Вот такой вопрос - а ядро у Вас какое?  Оригинальное c
> kernel.org или нет?

А что, тут есть самоубийцы, готовые сидеть на этой бочке??

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[sisyphus] Re: XFS filesystem crash

[Michael Shigorin]

On Thu, Dec 18, 2003 at 10:47:04PM +0200, Kylik Semuon wrote:
> За пол-года ни одной проблемы.

Это не срок...

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[sisyphus] Re: XFS filesystem crash

[Michael Shigorin]

On Fri, Dec 19, 2003 at 04:09:24AM +0300, Денис Смирнов wrote:
> BadBlock == потеря данных в одном блоке, причём, на современных
> хардах, незаметная для приложения (кроме как по потере этих
> самых данных). Вещь достаточно редкая, но встречающаяся, увы.

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

JAIH

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[sisyphus] Re: XFS filesystem crash

[Michael Shigorin]

On Fri, Dec 19, 2003 at 04:04:59AM +0300, Денис Смирнов wrote:
>  >> распространённых дистрибутивов (например Fedora).
>  > Ха-ха два раза.  Нет, не для федоры.  Скорее после того, как SuSE
>  > на rfs4 перейдет.
> Fedora массовее, за год тестирования на федоре пионеры, её
> использующиеся, обматерят каждый глюк :) После этого на него и
> перейдёт SuSE, и можно будет юзать :)

Это какая-то теория.

1) RH никогда не был особенно дружественным к reiserfs;
   справедливости ради, Ганс и его команда тоже не в белом.
2) какая польза от тестирования _файловой_ _системы_ пионерами?

На практике помимо тех спонсоров, с которыми namesys не попортила
отношения, активным тестированием и продвижением в массы rfs
занимается как раз именно что SuSE.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [sisyphus] Re: XFS filesystem crash

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 1204 bytes --]

On Fri, Dec 19, 2003 at 04:07:51AM +0300, Денис Смирнов wrote:
> On Thu, Dec 18, 2003 at 11:11:06PM +0300, Sergey Vlasov wrote:
> 
>  > Правильный диск не должен так себя вести (это некоторое время назад
>  > обсуждалось в lkml).  При чтении ничего переназначаться не будет.  А
>  > вот при записи в этот сектор действительно должно произойти
>  > переназначение.
> 
> Как поведёт себя диск, если не сможет _прочитать_ данные из сектора?
> Не сходятся у него контрольные суммы. Как он себя поведёт?

Должен вернуть ошибку чтения.

>  > Экспериментально проверялось на нескольких старых дисках Seagate -
>  > завершения работы badblocks на них так и не дождались, а вот после
>  > badblocks -w ни одного плохого сектора обнаружено не было (а
>  > информация SMART показала наличие большого количества переназначенных
>  > секторов).
> 
> Ясно. Хотя без официальных данных от производителей я бы не стал на это
> полагаться... По крайней мере для нынешнего IDE барахла.

Это точно...

По крайней мере, в упомянутом обсуждении этой проблемы в lkml человек с
обратным адресом из maxtor.com заявил, что их диски в этом отношении
работают правильно ;)  Т.е. переназначение делается именно при записи в
сектор.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] Re: XFS filesystem crash

[Serge Pavlovsky]

В ??, 18.12.2003, в 17:34, Peter S. Voronov пишет:
> Hello Michael,
> 
>  18 декабря 2003 г., you wrote:
> 
> MS> On Thu, Dec 18, 2003 at 03:00:29PM +0300, Roman Savelyev wrote:
> >> > Вот только квоты на reiserfs как жили во внешнем патче, так и
> >> > до сих пор живут.  А на ext3 при работе с квотами
> >> > обнаруживаются deadlock-и :(
> >> А, фигня. Reiser4 на подлёте.
> 
> MS> В конце сентября от авторитетного по теме человека прозвучало
> MS> "пользовать для данных НЕ РЕКОМЕНДУЕМ (пока)".
> 
> А возникает интересный (вредный) вопрос - а для чего рекомендуем, если
> не для данных ??????????????

для кода ;)
-- 
Serge Pavlovsky <pal@interexc.com>

[sisyphus] Re: XFS filesystem crash

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 490 bytes --]

On Thu, Dec 18, 2003 at 01:06:32AM +0300, Vitaly Lipatov wrote:
> Я собирался пересобрать утилиты для reiserfs и заодно сделать 
> пакет по образцу memtest86, который добавлял бы строку в меню, а 
> в initrd для ядра был прописан sh и статически собранный 

Если речь идет о меню загрузчика (grub или lilo), то лучше не писать
отдельный для этого скрипт, а согласовать интерфейс и внести его в
bootloader-utils.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[sisyphus] Re: [JT] XFS filesystem crash

[Vitaly Ostanin]

[-- Attachment #1: Type: text/plain, Size: 750 bytes --]

On Thu, 18 Dec 2003 19:47:53 +0200
Michael Shigorin <mike@osdn.org.ua> wrote:

> On Thu, Dec 18, 2003 at 04:38:07PM +0300, Vitaly Ostanin wrote:
> > Не пожалели. Mylex AcceleRAID 170. Аппаратный scsi raid 5,
> > вместе с дисками обошёлся за $1000. Лежит сейчас в тумбочке,
> > ждёт своей очереди на разбирательства :(
> 
> А что -- не разбирается??

Разбирается в аппаратном смысле? ;) В смысле проблем на
разбирательства пока нет времени. Этот raid так подгадил за
последние месяцы, что проще оказалось перенести систему на
IDE-винты.

Те письма в devel-kernel@ про dac960 были как раз на эту тему, я
тогда грешил на драйвер. Но это уже offtopic :)

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[sisyphus] Re: RAID (was: XFS filesystem crash)

[Vitaly Ostanin]

[-- Attachment #1: Type: text/plain, Size: 994 bytes --]

On 18 Dec 2003 22:47:04 +0200
Kylik Semuon <semask@tut.by> wrote:

<skipped/>

> > Наслушавшись негативных отзывов о разных RAID'ах я уже для
> > себя решил использовать только Software RAID. По крайней мере
> > он рано или поздно будет работать действительно _хорошо_.
> 
> Ну и зря
> Adaptek 2200 (2 канала, 64М на борту) - заводится из коробки
> M2.2 8 - НДД (2 зеркала + 5-ый). За пол-года ни одной проблемы.
> Счас там W2K (PDC). Второй начал умирать (материнка), так
> срочно пришлось переселять PDC.
> 
> Второй Mylex AcceleRAID 352 (правда под виндами) 2 - года нет
> проблем.

У нас второй такой же Mylex 170 тоже 2 года работает без проблем.
То, что проблем где-то долго нет - не показатель надёжности. Вот
то, что они есть - показатель.

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

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[sisyphus] Re: [JT] XFS filesystem crash

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 635 bytes --]

On Fri, Dec 19, 2003 at 01:32:10PM +0300, Vitaly Ostanin wrote:
> > > Не пожалели. Mylex AcceleRAID 170. Аппаратный scsi raid 5,
> > > вместе с дисками обошёлся за $1000. Лежит сейчас в тумбочке,
> > > ждёт своей очереди на разбирательства :(
> > А что -- не разбирается??
> Разбирается в аппаратном смысле? ;) В смысле проблем на
> разбирательства пока нет времени. Этот raid так подгадил за
> последние месяцы, что проще оказалось перенести систему на
> IDE-винты.

На пред. работе dac960 ни разу не дал поводу пенять на себя за
год+.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[sisyphus] Re: [JT] XFS filesystem crash

[Vitaly Ostanin]

[-- Attachment #1: Type: text/plain, Size: 796 bytes --]

On Fri, 19 Dec 2003 13:40:45 +0200
Michael Shigorin <mike@osdn.org.ua> wrote:

> On Fri, Dec 19, 2003 at 01:32:10PM +0300, Vitaly Ostanin wrote:
> > > > Не пожалели. Mylex AcceleRAID 170. Аппаратный scsi raid
> > > > 5, вместе с дисками обошёлся за $1000. Лежит сейчас в
> > > > тумбочке, ждёт своей очереди на разбирательства :(
> > > А что -- не разбирается??
> > Разбирается в аппаратном смысле? ;) В смысле проблем на
> > разбирательства пока нет времени. Этот raid так подгадил за
> > последние месяцы, что проще оказалось перенести систему на
> > IDE-винты.
> 
> На пред. работе dac960 ни разу не дал поводу пенять на себя за
> год+.

Да, в итоге дело оказалось в железке, а не в драйвере.

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] Re: XFS filesystem crash

[Kylik Semuon]

Отвалилась рассылка так буду отвечать на то что прочил в архиве

===================================
>Сколько за это время было реальных выходов из строя HDD?
>С уважением, Денис

Ниодного.
===================================

> За пол-года ни одной проблемы.
> Это не срок...

Ну серверу полгода всего. Молодой еще :))
===================================

>У нас второй такой же Mylex 170 тоже 2 года работает без проблем.
>То, что проблем где-то долго нет - не показатель надёжности. Вот
>то, что они есть - показатель.

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

Этого я не понимаю.


А насчет 352, вы наверное не представляется что это за девайс.
Для начала если лег винт - его достали вставили новый и все RAID
дальше сам все сделает САМ. (Проверено и на R1 и R5).
Также в любом RAIDE можно зарезервировать диск и при проблеме он
подлючится автоматом (не было возможности проверить, но такая опция есть
в свойствах RAID)
 
С уважением, Семен.

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Fri, Dec 19, 2003 at 11:36:34AM +0300, info wrote:

 > Когда я решал, какой вид RAID ставить, то прежде всего поискал в 
 > инете реальные истории тех людей, которые его восстанавливали 
 > после сбоев. Счас уже не помню где, но была пара леденящих душу 
 > историй, как RAID 5 после тяжелого сбоя восстановить так и не 
 > сумели. 

Вполне логично. RAID 5 очень зависим от программы, его реализующего.
 
 > Насколько я понимаю, RAID 5 хорош для преодоления относительно 
 > легких сбоев - с которыми он справляется без вашего участия. 

Он рассчитан на устранение любых сбоев без участия человека. Повреждение
любого сектора может быть обнаружено _автоматически_, и так же
автоматически исправлено. Точно так же как смерть диска может быть
обнаружена автоматически (как и для RAID 1), и новый диск подцеплен из hot
spare.
 
 > Его идеология довольно старая, когда дисковая память была ну 
 > очень дорогой, и делать даже однократное (не говоря уже о 
 > двух-трехкратном) зеркалирование казалось верхом 
 > расточительства. Так что RAID 5 есть компромисс - некоторое 
 > повышение надежности за счет не сильного перерасхода дискового 
 > пространства. 

Надёжность всё-таки у него выше, IMHO. По крайней мере в ситуации с
badblock'ами я просто не понимаю, каким образом RAID 0 её может обработать
корректно.
 
 > Что же касается RAID 1, то, насколько я понимаю, в описываемой 
 > Вами ситуации, когда один диск отражает badblock на один из 
 > своих резервных блоков, то ровно то же самое делает и второй 
 > диск - хотя у него этот блок и не bad. Может, я не прав.

Точно не так, ибо диск об этой замене никого не информирует. Просто в
какой-то момент сектор оказывается обнулённым. В результате RAID 1 просто
увидит два разных сектора -- какой из них он выберет?
 
 > Но RAID 1 я тестировал полгода на в усмерть убитом SCSI 1997-го 
 > года выпуска c морем badblock-ов, забивал его под завязку 
 > большими, но не слишком ценными файлами (да простят меня 
 > ALT-овцы - это были RPM-ы сизифуса), и все работало нормально 
 > жо тех пор, пока сказя окончательно не сдохла. Причем была пара 
 > ситуаций, когда приходилось делать --rebuild-tree - и даже 
 > после этого ничего не пропадало, все восстанавливалось.
 > Ну, а если хотите совсем уж надежности - сделайте два RAID 5 
 > массива, а потом зазеркалируйте их как RAID 1.

Для надёжности лучше, IMHO, вложить эти же деньги во внешний массив, с
отдельным источником питания и отдельным UPS, особенно если речь идёт о
больших объёмах и SCSI-дисках.

RAID 1 хорош в первую очередь _производительностью_, правильная реализация
может на чтении работать так же быстро, как и RAID 0. Поэтому связка RAID
0+1 видится мне оптимальной для массивов IDE-дисков. Для SCSI это слишком
дорого и неэффективно, IMHO. 

А, да, ещё одно применение -- когда на сервер ставится только 2 харда. По
финансовым соображениям. Тогда выбора нет -- только RAID 1.

-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Fri, Dec 19, 2003 at 12:55:30PM +0300, Sergey Vlasov wrote:

 >>> Правильный диск не должен так себя вести (это некоторое время назад
 >>> обсуждалось в lkml).  При чтении ничего переназначаться не будет.  А
 >>> вот при записи в этот сектор действительно должно произойти
 >>> переназначение.
 >> Как поведёт себя диск, если не сможет _прочитать_ данные из сектора?
 >> Не сходятся у него контрольные суммы. Как он себя поведёт?
 > Должен вернуть ошибку чтения.

Ага. А как это обработает система? До реализации Software RAID эта
информация дойдёт?

/me вспоминает историю как под полуосью дятел умирал, зацикливаясь на
попытках прочитать отдельные сектора, единственное что помогло -- утилита
от IBM, но она-то по любому обнуляет данные :(
 
 >>> Экспериментально проверялось на нескольких старых дисках Seagate -
 >>> завершения работы badblocks на них так и не дождались, а вот после
 >>> badblocks -w ни одного плохого сектора обнаружено не было (а
 >>> информация SMART показала наличие большого количества переназначенных
 >>> секторов).
 >> Ясно. Хотя без официальных данных от производителей я бы не стал на это
 >> полагаться... По крайней мере для нынешнего IDE барахла.
 > Это точно...
 > По крайней мере, в упомянутом обсуждении этой проблемы в lkml человек с
 > обратным адресом из maxtor.com заявил, что их диски в этом отношении
 > работают правильно ;)  Т.е. переназначение делается именно при записи в
 > сектор.

Это хорошо, буду знать.

-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Fri, Dec 19, 2003 at 11:30:28AM +0200, Michael Shigorin wrote:

 >> BadBlock == потеря данных в одном блоке, причём, на современных
 >> хардах, незаметная для приложения (кроме как по потере этих
 >> самых данных). Вещь достаточно редкая, но встречающаяся, увы.
 > Денис, что-то Вы странное расказываете.  Редкий блок вот так
 > сразу и долетит за середину диапазона вероятности читаемости;
 > современные винты занимаются ремапом не когда уже поздно, а когда
 > оная читаемость падает ниже порога.

Возможно такое моё восприятие связано именно с эпохой массового вылета
дятлов. На моих глазах два дятла так умерли.

Я только сейчас вспомнию историю более чётко -- эти дятлы ремонтировались
IBM'овской утилитой, возможно это она обнуляла, сами дятлы просто
зацикливались на операции чтения (или это ОС циклилась?).
 
-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Fri, Dec 19, 2003 at 11:34:34AM +0200, Michael Shigorin wrote:

 > Это какая-то теория.
 > 1) RH никогда не был особенно дружественным к reiserfs;
 >    справедливости ради, Ганс и его команда тоже не в белом.
 > 2) какая польза от тестирования _файловой_ _системы_ пионерами?

А где вы возьмёте такое количество непионеров, которые будут
эксплуатировать FS в жёстких условиях (типа как у меня один знакомый был,
ему было лениво долго ждать завершения работы, поэтому он выключал систему
_только_ методом power-off), давай ей переполнятся, и.т.д., делая всё то,
до чего нормальный специалист в трезвом уме не догадается :)
 
 > На практике помимо тех спонсоров, с которыми namesys не попортила
 > отношения, активным тестированием и продвижением в массы rfs
 > занимается как раз именно что SuSE.
 
Если можно -- хотелось бы узнать подробнее про "попортила отношения". Чем
именно и с кем namesys успела поругаться?
 
-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Fri, Dec 19, 2003 at 12:19:25PM +0300, Roman Savelyev wrote:

 >> Если кратко -- в реализации JFS для Linux я пока не вижу ни одного
 >> преимущества перед остальными имеющимися FS.
 > Оно надо в основном IBM-у, для совместимости носителей с AIX.

Вывод: тем, кто не связан с AIX'ом лучше всего не тратить своё время и
игнорировать существование этой FS (существующей только для совместимости,
получается).

 >> специальных задач (cramfs), либо непонятно для чего (JFS). Разумеется
 >> IMHO.
 > JFFS2 - тоже очень и очень хороша для своих задачек.

Да. Она относится к той же группе что и cramfs -- специализированые
файловые системы для узкоспециализированых задач.

-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Fri, Dec 19, 2003 at 12:21:10PM +0300, Roman Savelyev wrote:

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

Ну там обычно всё равно не стоит экономить на потреблении процессора
файловой системой, IMHO, конечно.

-- 
С уважением, Денис

http://freesource.info

Re: [sisyphus] Re: XFS filesystem crash

[Led]

Денис Смирнов wrote:

>On Fri, Dec 19, 2003 at 11:36:34AM +0300, info wrote:
>
> > Когда я решал, какой вид RAID ставить, то прежде всего поискал в 
> > инете реальные истории тех людей, которые его восстанавливали 
> > после сбоев. Счас уже не помню где, но была пара леденящих душу 
> > историй, как RAID 5 после тяжелого сбоя восстановить так и не 
> > сумели. 
>
>Вполне логично. RAID 5 очень зависим от программы, его реализующего.
> 
> > Насколько я понимаю, RAID 5 хорош для преодоления относительно 
> > легких сбоев - с которыми он справляется без вашего участия. 
>
>Он рассчитан на устранение любых сбоев без участия человека. Повреждение
>любого сектора может быть обнаружено _автоматически_, и так же
>автоматически исправлено. Точно так же как смерть диска может быть
>обнаружена автоматически (как и для RAID 1), и новый диск подцеплен из hot
>spare.
> 
> > Его идеология довольно старая, когда дисковая память была ну 
> > очень дорогой, и делать даже однократное (не говоря уже о 
> > двух-трехкратном) зеркалирование казалось верхом 
> > расточительства. Так что RAID 5 есть компромисс - некоторое 
> > повышение надежности за счет не сильного перерасхода дискового 
> > пространства. 
>
>Надёжность всё-таки у него выше, IMHO. По крайней мере в ситуации с
>badblock'ами я просто не понимаю, каким образом RAID 0 её может обработать
>корректно.
> 
> > Что же касается RAID 1, то, насколько я понимаю, в описываемой 
> > Вами ситуации, когда один диск отражает badblock на один из 
> > своих резервных блоков, то ровно то же самое делает и второй 
> > диск - хотя у него этот блок и не bad. Может, я не прав.
>
>Точно не так, ибо диск об этой замене никого не информирует. Просто в
>какой-то момент сектор оказывается обнулённым. В результате RAID 1 просто
>увидит два разных сектора -- какой из них он выберет?
>  
>
Почему это он будет "обнулённым"? Он будет "сбойным". Из двух секторов 
(сбойного и несбойного) RAID1 выберет несбойный...

> 
> > Но RAID 1 я тестировал полгода на в усмерть убитом SCSI 1997-го 
> > года выпуска c морем badblock-ов, забивал его под завязку 
> > большими, но не слишком ценными файлами (да простят меня 
> > ALT-овцы - это были RPM-ы сизифуса), и все работало нормально 
> > жо тех пор, пока сказя окончательно не сдохла. Причем была пара 
> > ситуаций, когда приходилось делать --rebuild-tree - и даже 
> > после этого ничего не пропадало, все восстанавливалось.
> > Ну, а если хотите совсем уж надежности - сделайте два RAID 5 
> > массива, а потом зазеркалируйте их как RAID 1.
>
>Для надёжности лучше, IMHO, вложить эти же деньги во внешний массив, с
>отдельным источником питания и отдельным UPS, особенно если речь идёт о
>больших объёмах и SCSI-дисках.
>
>RAID 1 хорош в первую очередь _производительностью_, правильная реализация
>может на чтении работать так же быстро, как и RAID 0. 
>
Неужели? С какой это стати RAID1 может быть таким же быстрым, как RAID0?
AFAIK при правильной организации RAID5 значительно быстрее RAID1 и 
немного уступает RAID0.

>Поэтому связка RAID
>0+1 видится мне оптимальной для массивов IDE-дисков. Для SCSI это слишком
>дорого и неэффективно, IMHO.
>  
>
Зеркалирование на IDE вобще себя не оправдывает... По крайней мере не 
видел IDE RAID с автовосстановлением.
А в этом случает проще, надёжнее и дешевле периодический бэкап.

>А, да, ещё одно применение -- когда на сервер ставится только 2 харда. По
>финансовым соображениям. Тогда выбора нет -- только RAID 1.
>
>  
>
По финансовым соображениям в таком случае ИМХО следует использовать 
обычные бэкапы.
А если нужна надёжность+быстрое(прозрачное) восстановление после сбоя, 
тогда "финансовые соображения" должны потесниться...
Не бывает "так же надёжно, но в два раза дешевле"....

Led.

Re: [sisyphus] Re: XFS filesystem crash

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 1228 bytes --]

On Fri, Dec 19, 2003 at 07:33:20PM +0300, Денис Смирнов wrote:
> On Fri, Dec 19, 2003 at 12:55:30PM +0300, Sergey Vlasov wrote:
> 
>  >>> Правильный диск не должен так себя вести (это некоторое время назад
>  >>> обсуждалось в lkml).  При чтении ничего переназначаться не будет.  А
>  >>> вот при записи в этот сектор действительно должно произойти
>  >>> переназначение.
>  >> Как поведёт себя диск, если не сможет _прочитать_ данные из сектора?
>  >> Не сходятся у него контрольные суммы. Как он себя поведёт?
>  > Должен вернуть ошибку чтения.
> 
> Ага. А как это обработает система? До реализации Software RAID эта
> информация дойдёт?

Должна дойти.  Вот только md при обнаружении первого же такого сектора
объявит дохлым всё устройство.

> /me вспоминает историю как под полуосью дятел умирал, зацикливаясь на
> попытках прочитать отдельные сектора, единственное что помогло -- утилита
> от IBM, но она-то по любому обнуляет данные :(

На самом деле могло помочь что-нибудь вроде badblocks -n, вот только
при большом количестве битых секторов эта операция может длиться очень
долго.  И я не проверял, забивается ли при этом нулями тот сектор,
который не удалось прочитать (для переназначения нужна именно попытка
записи).

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] Re: XFS filesystem crash

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 472 bytes --]

On Fri, Dec 19, 2003 at 06:51:35PM +0200, Led wrote:
> >RAID 1 хорош в первую очередь _производительностью_, правильная реализация
> >может на чтении работать так же быстро, как и RAID 0. 
> >
> Неужели? С какой это стати RAID1 может быть таким же быстрым, как RAID0?
> AFAIK при правильной организации RAID5 значительно быстрее RAID1 и 
> немного уступает RAID0.

Ещё к вопросу о скорости и оптимизации разных типов RAID:

http://testing.lkml.org/slashdot.php?mid=437521

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] Re: XFS filesystem crash

[Denis Smirnov]

On Fri, Dec 19, 2003 at 04:53:32PM +0200, Kylik Semuon wrote:

 >>Сколько за это время было реальных выходов из строя HDD?
 > Ниодного.

В таком случае пока неизвестно есть ли хоть какой-то прок от этого
RAID-контроллера.
 
 > А насчет 352, вы наверное не представляется что это за девайс.
 > Для начала если лег винт - его достали вставили новый и все RAID
 > дальше сам все сделает САМ. (Проверено и на R1 и R5).
 > Также в любом RAIDE можно зарезервировать диск и при проблеме он
 > подлючится автоматом (не было возможности проверить, но такая опция есть
 > в свойствах RAID)

Вся проблема не в наличии функциональности (в наше время это не
проблема), а в грамотной её реализации (а с этим в наше время _серьёзная_
проблема).
 
-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Fri, Dec 19, 2003 at 10:25:28PM +0300, Sergey Vlasov wrote:

 >> Ага. А как это обработает система? До реализации Software RAID эта
 >> информация дойдёт?
 > Должна дойти.  Вот только md при обнаружении первого же такого сектора
 > объявит дохлым всё устройство.

Откуда информация?
 
 >> /me вспоминает историю как под полуосью дятел умирал, зацикливаясь на
 >> попытках прочитать отдельные сектора, единственное что помогло -- утилита
 >> от IBM, но она-то по любому обнуляет данные :(
 > На самом деле могло помочь что-нибудь вроде badblocks -n, вот только
 > при большом количестве битых секторов эта операция может длиться очень
 > долго.  И я не проверял, забивается ли при этом нулями тот сектор,
 > который не удалось прочитать (для переназначения нужна именно попытка
 > записи).

Дело в том, что его совсем циклит. Я не ждал сколько он может пытаться
читать один сектор, но _очень_ долго :( Поэтому тут хотелось бы получив
ошибку сразу отвалиться и взять информацию с зеркального диска.

-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Fri, Dec 19, 2003 at 06:51:35PM +0200, Led wrote:

 >>Для надёжности лучше, IMHO, вложить эти же деньги во внешний массив, с
 >>отдельным источником питания и отдельным UPS, особенно если речь идёт о
 >>больших объёмах и SCSI-дисках.
 >>RAID 1 хорош в первую очередь _производительностью_, правильная реализация
 >>может на чтении работать так же быстро, как и RAID 0. 
 > Неужели? С какой это стати RAID1 может быть таким же быстрым, как RAID0?
 > AFAIK при правильной организации RAID5 значительно быстрее RAID1 и 
 > немного уступает RAID0.

При чтении можно делать то же самое, что делается в случае stripe
(распределять разные запросы на чтение к разным устройствам), таким
образом выигрывая _и_ на seek, _и_ на пропускной способности. То есть,
теоретически, можно достичь даже большей скорости чем у RAID 0 (правда я
сомневаюсь что реально это делает хотя бы кто-нибудь). Особенно хороший
выигрыш это даст на IDE (при умной реализации).

RAID 5 требует для каждой операции записи как минимум 2 операции чтения
(сектора в который пишем и сектора с контрольной суммой) и две операции
записи. В отличии от двух операций записи для зеркала.

 >> Поэтому связка RAID
 >> 0+1 видится мне оптимальной для массивов IDE-дисков. Для SCSI это слишком
 >> дорого и неэффективно, IMHO.
 > Зеркалирование на IDE вобще себя не оправдывает... По крайней мере не 
 > видел IDE RAID с автовосстановлением.
 > А в этом случает проще, надёжнее и дешевле периодический бэкап.

Backup необходим в любом случае, это аксиома. В не зависимости от уровня
защищённости.
 
 >> А, да, ещё одно применение -- когда на сервер ставится только 2 харда. По
 >> финансовым соображениям. Тогда выбора нет -- только RAID 1.
 > По финансовым соображениям в таком случае ИМХО следует использовать 
 > обычные бэкапы.
 > А если нужна надёжность+быстрое(прозрачное) восстановление после сбоя, 
 > тогда "финансовые соображения" должны потесниться...
 > Не бывает "так же надёжно, но в два раза дешевле"....

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

/me радуется LVM'овским snapshot'ам, и своим надеждам на то, что скоро они
будут применимы для этой цели.
 
-- 
С уважением, Денис

http://freesource.info

Re: [sisyphus] Re: XFS filesystem crash

[Kylik Semuon]

Рассылка по прежнему чего-то ниходить :((

 > >>Сколько за это время было реальных выходов из строя HDD?
 > > Ниодного.

Я этому несказанно рад.

> В таком случае пока неизвестно есть ли хоть какой-то прок от этого
> RAID-контроллера.

Честно говорю, не понял.
Прок в нем есть - он работает и это существенно.
 
 > А насчет 352, вы наверное не представляется что это за девайс.
 > Для начала если лег винт - его достали вставили новый и все RAID
 > дальше сам все сделает САМ. (Проверено и на R1 и R5).
 > Также в любом RAIDE можно зарезервировать диск и при проблеме он
 > подлючится автоматом (не было возможности проверить, но такая опция есть
 > в свойствах RAID)

> Вся проблема не в наличии функциональности (в наше время это не
> проблема), а в грамотной её реализации (а с этим в наше время _серьёзная_
> проблема).

Для начала - это работающая функциональность, не зависящая от OS.

А остальное уже раньше говорили.

PS. А про BADBLOCK еще раз повторю. Если они видны для ОС, такой винт 
уже повод покупать новый (не задуматься, а ПОКУПАТЬ).

PSS Я просто это 2 года назад испытал на себе. 4-00 выключил комп
в 6-00 его уже ОС не смогла прочитать (и гарантия была очень
слабым утешением).

PSSS SoftRAID - это для понта и не более. Ну вот хочется RAID и все.
Ногами не пинать.


-- 
С уважением, Семен.

Re: [sisyphus] Re: XFS filesystem crash

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]

On Fri, Dec 19, 2003 at 11:52:13PM +0300, Денис Смирнов wrote:
> On Fri, Dec 19, 2003 at 10:25:28PM +0300, Sergey Vlasov wrote:
> 
>  >> Ага. А как это обработает система? До реализации Software RAID эта
>  >> информация дойдёт?
>  > Должна дойти.  Вот только md при обнаружении первого же такого сектора
>  > объявит дохлым всё устройство.
> 
> Откуда информация?

drivers/md/raid1.c: raid1_end_request --> md_error --> raid1_error -->
mark_disk_bad

>  >> /me вспоминает историю как под полуосью дятел умирал, зацикливаясь на
>  >> попытках прочитать отдельные сектора, единственное что помогло -- утилита
>  >> от IBM, но она-то по любому обнуляет данные :(
>  > На самом деле могло помочь что-нибудь вроде badblocks -n, вот только
>  > при большом количестве битых секторов эта операция может длиться очень
>  > долго.  И я не проверял, забивается ли при этом нулями тот сектор,
>  > который не удалось прочитать (для переназначения нужна именно попытка
>  > записи).
> 
> Дело в том, что его совсем циклит. Я не ждал сколько он может пытаться
> читать один сектор, но _очень_ долго :( Поэтому тут хотелось бы получив
> ошибку сразу отвалиться и взять информацию с зеркального диска.

Там ещё в драйвере ide-disk стоит 8 повторов...

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Sat, Dec 20, 2003 at 07:16:48PM +0200, Kylik Semuon wrote:
 > Рассылка по прежнему чего-то ниходить :((

? Сегодня ко мне несколько сообщений пришло.
 
 >>>>Сколько за это время было реальных выходов из строя HDD?
 >>> Ниодного.
 > Я этому несказанно рад.
 >> В таком случае пока неизвестно есть ли хоть какой-то прок от этого
 >> RAID-контроллера.
 > Честно говорю, не понял.
 > Прок в нем есть - он работает и это существенно.

Дык какая польза от RAID'то? Польза от RAID заключается в том, что
повреждение одного диска не приводит даже к остановке работы сервиса.
Насколько качественно он работает видно _только_ в ситуации (реальной или
тестовой) сбоя дисков. До тех пор нельзя с уверенностью сказать является
ли контроллер хоть чуточку полезным.
 
 >  > А насчет 352, вы наверное не представляется что это за девайс.
 >  > Для начала если лег винт - его достали вставили новый и все RAID
 >  > дальше сам все сделает САМ. (Проверено и на R1 и R5).
 >  > Также в любом RAIDE можно зарезервировать диск и при проблеме он
 >  > подлючится автоматом (не было возможности проверить, но такая опция есть
 >  > в свойствах RAID)
 > > Вся проблема не в наличии функциональности (в наше время это не
 > > проблема), а в грамотной её реализации (а с этим в наше время _серьёзная_
 > > проблема).
 > Для начала - это работающая функциональность, не зависящая от OS.
 > А остальное уже раньше говорили.

Как только что выяснилось вами эта функциональность протестирована так и
не была.

Независимость от ОС меня неинтересует вообще. Для RAID-контроллера меня
интересует в первую очередь одно -- надёжность. Во вторую очередь
скорость. В третью -- удобство использованияю В четвёртую -- удобство
конфигурации. 

Так вот в случае Software реализации у меня есть серьёзное преимущество в
надёжности -- я могу посмотреть код сам, при желании. А кроме меня его
посмотрят ещё тысячи людей по всему миру. А код прошивки этого контроллера
видели единицы, и гарантия того, что он вдруг не сглючит весьма низка.
 
 > PS. А про BADBLOCK еще раз повторю. Если они видны для ОС, такой винт 
 > уже повод покупать новый (не задуматься, а ПОКУПАТЬ).

Круто. Но если он таки _появился_, то система _не имеет права_ в этом
случае терять данные. Хоть тресни. Автоматически выкинуть этот диск из
массива и подключить hot spare -- обязана, пнуть ногой (в форме email,
SMS, IM) обязана, а вот данные терять ни-ни.
 
 > PSS Я просто это 2 года назад испытал на себе. 4-00 выключил комп
 > в 6-00 его уже ОС не смогла прочитать (и гарантия была очень
 > слабым утешением).

Знаю, сам данные терял. Теперь привычка backup делать :)
 
 > PSSS SoftRAID - это для понта и не более. Ну вот хочется RAID и все.
 > Ногами не пинать.

Фраза без обоснований совсем. Всё что я услышал это то, что SoftRAID
несовместим между разными ОС, ну дык и используемая мною ext3 не
совместима, так что этот вопрос меня не волнует.

Железное решение _может_ быть быстрее и надёжнее. Посему я и спрашивал о
том как себя вёл контроллер, который вы называете хорошим, в ситуациях
сбоя HDD (для предотвращения последствий которых RAID и нужен). 
 
-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: XFS filesystem crash

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 848 bytes --]

On Fri, Dec 19, 2003 at 07:30:59PM +0300, Денис Смирнов wrote:
>  > Так что RAID 5 есть компромисс - некоторое повышение
>  > надежности за счет не сильного перерасхода дискового
> Надёжность всё-таки у него выше, IMHO. По крайней мере в
> ситуации с badblock'ами я просто не понимаю, каким образом RAID
> 0 её может обработать корректно.

Так что с чем сравнивают?

RAID0 < RAID5 < RAID1 в плане надежности при прочих равных.

По очень простым причинам -- 0 не надежнее самого слабого звена
по определению, 1 не менее надежен, чем самое крепкое звено, а 5
достаточно сложен, чтобы говорить о (прикладной) надежности,
превышающей 1, было малоосмысленно.

Вообще говоря -- коэффициент резервирования не отменяли.

PS: ха-ачу hardware@altlinux.ru! ;-)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[sisyphus] Re: XFS filesystem crash

[Michael Shigorin]

On Fri, Dec 19, 2003 at 07:39:38PM +0300, Денис Смирнов wrote:
>  > 2) какая польза от тестирования _файловой_ _системы_ пионерами?
> А где вы возьмёте такое количество непионеров, которые будут
> эксплуатировать FS в жёстких условиях

Продакшн.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [sisyphus] Re: XFS filesystem crash

[Vitaly Lipatov]

On 19 Декабрь 2003 13:26, Alexey Tourbin wrote:

> Если речь идет о меню загрузчика (grub или lilo), то лучше не
> писать отдельный для этого скрипт, а согласовать интерфейс и
> внести его в bootloader-utils.
Спасибо за совет. Я надеюсь, в memtest86 так и сделано, я бы на 
него в первую очередь посмотрел, как на образец.

-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! LaTeX! LyX!

Re: [sisyphus] XFS filesystem crash

[Vitaly Lipatov]

On 19 Декабрь 2003 11:17, info wrote:
> Виталий, у меня из головы не шли Ваши накрытия рейзера -
> потому как сам на нем сижу... Вот такой вопрос - а ядро у Вас
> какое? Оригинальное c kernel.org или нет? Какие патчи? И,
> главное, если ли среди них low-latency sheduler? Дело в том,
> что эта штука дописывает свои куски в коды всех основных
> файловых систем (ext2/ext3/reiser); причем на ядре 2.4.23 патч
> у меня в двух местах  провалился, и не где-нибудь, а на 
> fs/inode.c и fs/buffer.c. А занимается она, как известно, тем,
> что целенаправленно тормозит в том числе и работу с файловой
> системой ради качества звука. Не в ней ли дело?
Дело в том, что это давно уже идёт (наверное, изначально), с 
разными ядрами и прочее. С low-latency и без него. Ядра я всегда 
использую из Сизифа уже собранные.

-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! LaTeX! LyX!

[sisyphus] Re: XFS filesystem crash

[Michael Shigorin]

On Sat, Dec 20, 2003 at 11:35:07PM +0300, Vitaly Lipatov wrote:
> > Если речь идет о меню загрузчика (grub или lilo), то лучше не
> > писать отдельный для этого скрипт, а согласовать интерфейс и
> > внести его в bootloader-utils.
> Спасибо за совет. Я надеюсь, в memtest86 так и сделано, я бы на 
> него в первую очередь посмотрел, как на образец.

Не-а :(  По крайней мере на сейчас.

Хотел, да не получалось без модификации bootloader-utils или
Common.pm того.  Кажется, в BTS должны быть записи на memtest86
по этому поводу.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Sat, Dec 20, 2003 at 08:35:47PM +0200, Michael Shigorin wrote:

 >>> 2) какая польза от тестирования _файловой_ _системы_ пионерами?
 >> А где вы возьмёте такое количество непионеров, которые будут
 >> эксплуатировать FS в жёстких условиях
 > Продакшн.

В продакшн, как ни странно, условия работы гораздо мягче чем у любого
пионера. Я не верю, что вы поставите в продакшн систему, имеющую хоть
минимальную важность, без UPS'а, в корпус с никаким охлаждением и жутким
БП, с супер-пупер хардами на 250Gb, которые ничем при этом не
охлаждаются, на IDE RAID контроллер от Promise, завернёте всё это в ткань
(чтобы не шумело) и включите в одну розетку с микроволновкой и
электрическим чайником.

У вас за год не наберётся столько сбоев железа, сколько у нормального
пионера за день бывает :)

======================================================================
Классическая ошибка, которую совершают разработчики абсолютно надёжных
систем, --  недооценка изобретательности клинических идиотов
                                          (с) Дуглас Адамс
======================================================================

-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Sat, Dec 20, 2003 at 08:49:09PM +0300, Sergey Vlasov wrote:

 >>> Должна дойти.  Вот только md при обнаружении первого же такого сектора
 >>> объявит дохлым всё устройство.
 >> Откуда информация?
 > drivers/md/raid1.c: raid1_end_request --> md_error --> raid1_error -->
 > mark_disk_bad

Спасибо.
 
 >>>> /me вспоминает историю как под полуосью дятел умирал, зацикливаясь на
 >>>> попытках прочитать отдельные сектора, единственное что помогло -- утилита
 >>>> от IBM, но она-то по любому обнуляет данные :(
 >>> На самом деле могло помочь что-нибудь вроде badblocks -n, вот только
 >>> при большом количестве битых секторов эта операция может длиться очень
 >>> долго.  И я не проверял, забивается ли при этом нулями тот сектор,
 >>> который не удалось прочитать (для переназначения нужна именно попытка
 >>> записи).
 >> Дело в том, что его совсем циклит. Я не ждал сколько он может пытаться
 >> читать один сектор, но _очень_ долго :( Поэтому тут хотелось бы получив
 >> ошибку сразу отвалиться и взять информацию с зеркального диска.
 > Там ещё в драйвере ide-disk стоит 8 повторов...

Ясно. Но это хоть, при желании исправить можно...

-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Sat, Dec 20, 2003 at 08:08:50PM +0200, Michael Shigorin wrote:

 >>> Так что RAID 5 есть компромисс - некоторое повышение
 >>> надежности за счет не сильного перерасхода дискового
 >> Надёжность всё-таки у него выше, IMHO. По крайней мере в
 >> ситуации с badblock'ами я просто не понимаю, каким образом RAID
 >> 0 её может обработать корректно.
 > Так что с чем сравнивают?

Я ошибся, имел в виду RAID 1, разумеется. Сравнивали 1 и 5.
 
 > RAID0 < RAID5 < RAID1 в плане надежности при прочих равных.
 > По очень простым причинам -- 0 не надежнее самого слабого звена
 > по определению, 1 не менее надежен, чем самое крепкое звено, а 5
 > достаточно сложен, чтобы говорить о (прикладной) надежности,
 > превышающей 1, было малоосмысленно.

То есть:

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

Я правильно понимаю?

Вопрос -- меньшая надёжность RAID 5 по вашемум мнению _теоретическая_ (то
есть идеальный RAID 5 хуже идеального RAID 1), или _практическая_
(существующие реализации RAID 5 хуже чем реализации RAID 1)? 
 
 > Вообще говоря -- коэффициент резервирования не отменяли.

wtf 'коэффициент резервирования'?
 
 > PS: ха-ачу hardware@altlinux.ru! ;-)

Я тоже :)

-- 
С уважением, Денис

http://freesource.info

Re: [sisyphus] Re: XFS filesystem crash

[Kylik Semuon]

Денису.

>Железное решение _может_ быть быстрее и надёжнее. 
Так и должен быть и быстрее и надежнее. Смысл тогда платить деньги (не 
одну сотку стоят, тысячи)

>Посему я и спрашивал о том как себя вёл контроллер, который вы
>называете хорошим, в ситуациях сбоя HDD (для предотвращения 
>последствий которых >RAID и нужен). 

Нет у меня битых винтов. Техника устаревшая, но рабочая (здесь два года

Re: [sisyphus] Re: XFS filesystem crash

[Kylik Semuon]

Прошу прощения.
Не размялся еще за клавой. Письмо ушло не даделаным.

Денису продолжаем.

На 352 тестил на живых винтах. При включенной машине 
доставал винты по очереди (только с умом. Давал RAID
востановиться).

Ну а если в руководстве написано что при вылете 
HDD RAID будет работать, я должен этому поверить, или 
через некоторое время проверить сам. Но проблем не дол-
жно быть, или в нете уже был вой по этому поводу.

Ну правда есть ограничения для тогоже RAID5 Если вылетят
два винта сразу, то это очень плохо (посему в RAID и ставят
HDD и разных партий и при покупке это обговаривается).

PS Есть биты HDD SCSI 80-pin шли - проверю. Тем более сервак
вчера остановил в ремонт (система не видет 2-го камня).

PSS SoftRaid - лично мое мнение и с интересной предычторией.
На NT4 без UPS он просто испортился и все. Было это давно и сейчас
никому не интересно.

PSSS в этом треде было много разумных мыслей, перечитай внимательно
и если у конторы средства позволяют купите аппаратный и не ищите 
приключений на одно место

С уважением, Семен.

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Sun, Dec 21, 2003 at 10:07:58AM +0200, Kylik Semuon wrote:

 > На 352 тестил на живых винтах. При включенной машине 
 > доставал винты по очереди (только с умом. Давал RAID
 > востановиться).

Ага, ясно.
 
 > Ну а если в руководстве написано что при вылете 
 > HDD RAID будет работать, я должен этому поверить, или 
 > через некоторое время проверить сам. Но проблем не дол-
 > жно быть, или в нете уже был вой по этому поводу.

Тихое подвывание про глюки в различных контроллерах я периодически слышу.
 
 > Ну правда есть ограничения для тогоже RAID5 Если вылетят
 > два винта сразу, то это очень плохо (посему в RAID и ставят
 > HDD и разных партий и при покупке это обговаривается).
 > PS Есть биты HDD SCSI 80-pin шли - проверю. Тем более сервак
 > вчера остановил в ремонт (система не видет 2-го камня).
 > PSS SoftRaid - лично мое мнение и с интересной предычторией.
 > На NT4 без UPS он просто испортился и все. Было это давно и сейчас
 > никому не интересно.
 > PSSS в этом треде было много разумных мыслей, перечитай внимательно
 > и если у конторы средства позволяют купите аппаратный и не ищите 
 > приключений на одно место

Не все йогурты одинаковы полезны. В смысле не все аппаратные RAID'ы
реально надёжны. И для выяснения что же именно надёжно я предпочитаю
заранее собирать отзывы. 
 
-- 
С уважением, Денис

http://freesource.info

hardware@ wanted (was: [sisyphus] XFS filesystem crash)

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 824 bytes --]

On Sun, Dec 21, 2003 at 01:50:33AM +0300, Денис Смирнов wrote:
> RAID 1 -- скорость чтения выше чем у отдельного диска, записи
> равна самому медленному диску.

На запись не уверен: размером страйпа /вроде/ можно играться.

> RAID 5 -- экономит пространство, по всем остальным параметрам
> идентичен RAID 1.

Нет.  По восстановлению, как уже упоминалось -- куда сложнее.

>  > Вообще говоря -- коэффициент резервирования не отменяли.
> wtf 'коэффициент резервирования'?

На скольких носителях этот_байт лежит.

>  > PS: ха-ачу hardware@altlinux.ru! ;-)
> Я тоже :)

2 team: во избежание регулярных (при этом полезных) офтопиков --
давайте-ка возьмем да и сделаем.  А то придется @linux.kiev.ua
поднимать, а там и так очередь.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[sisyphus] Re: XFS filesystem crash

[Michael Shigorin]

On Sun, Dec 21, 2003 at 01:19:39AM +0300, Денис Смирнов wrote:
>  >>> 2) какая польза от тестирования _файловой_ _системы_ пионерами?
>  >> А где вы возьмёте такое количество непионеров, которые будут
>  >> эксплуатировать FS в жёстких условиях
>  > Продакшн.
> В продакшн, как ни странно, условия работы гораздо мягче чем у
> любого пионера.

Неправильно выразился.  Предшествующие помещению/выпуску в
продакшн процессы, разумеется.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Sun, Dec 21, 2003 at 01:59:30PM +0200, Michael Shigorin wrote:

 >>>>> 2) какая польза от тестирования _файловой_ _системы_ пионерами?
 >>>> А где вы возьмёте такое количество непионеров, которые будут
 >>>> эксплуатировать FS в жёстких условиях
 >>> Продакшн.
 >> В продакшн, как ни странно, условия работы гораздо мягче чем у
 >> любого пионера.
 > Неправильно выразился.  Предшествующие помещению/выпуску в
 > продакшн процессы, разумеется.

Тогда согласен. С уточнением, что хороший ламер может создать тестовую
ситуацию похлеще любой лаборотории, поэтому после внутреннего полноценного
тестирования, полезно протестировать и на них. Множества ошибок
отлавливаемых специалистами-тестерами и ламерами-обыкновенными хоть и
пересекаются, но каждое из них содержит что-то, чего нет в другом.
 
-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: hardwa@ wanted (was: XFS filesystem crash)

[Денис Смирнов]

On Sun, Dec 21, 2003 at 01:56:56PM +0200, Michael Shigorin wrote:

 >> RAID 1 -- скорость чтения выше чем у отдельного диска, записи
 >> равна самому медленному диску.
 > На запись не уверен: размером страйпа /вроде/ можно играться.

Думаю что зависит от реализации. На RAID 1 (не 0) при чтении мы можем
вообще не думать о структуре массива, а просто раскидывать разные запросы
по разным дискам.
 
 >> RAID 5 -- экономит пространство, по всем остальным параметрам
 >> идентичен RAID 1.
 > Нет.  По восстановлению, как уже упоминалось -- куда сложнее.

Согласен.
 
 >>> Вообще говоря -- коэффициент резервирования не отменяли.
 >> wtf 'коэффициент резервирования'?
 > На скольких носителях этот_байт лежит.

Ясно.
 
 >>> PS: ха-ачу hardware@altlinux.ru! ;-)
 >> Я тоже :)
 > 2 team: во избежание регулярных (при этом полезных) офтопиков --
 > давайте-ка возьмем да и сделаем.  А то придется @linux.kiev.ua
 > поднимать, а там и так очередь.

Кроме того одной очень полезной функцией этой рассылки (и народа там
обитающего) может быть составление нормального HCL. Лично мне такого
документа _очень_ не хватает.
 

-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: hardware@ wanted (was: XFS filesystem crash)

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]

On Mon, Dec 22, 2003 at 03:22:12AM +0300, Денис Смирнов wrote:
>  >>> PS: ха-ачу hardware@altlinux.ru! ;-)
>  >> Я тоже :)
>  > 2 team: во избежание регулярных (при этом полезных) офтопиков --
>  > давайте-ка возьмем да и сделаем.  А то придется @linux.kiev.ua
>  > поднимать, а там и так очередь.
> Кроме того одной очень полезной функцией этой рассылки (и
> народа там обитающего) может быть составление нормального HCL.
> Лично мне такого документа _очень_ не хватает.

О чем и речь.

Вообще цель каждого хорошего ресурса (в т.ч. рассылки) --
концентрировать аудиенцию (и, соотв., информацию) по выделенным и
определенным темам с целью достижения хорошего SNR.

Пока "железные" вопросы обсуждаются в софтово-социальных
рассылках (devel@, sisyphus@, community@) -- собирать результаты
трудно, если вообще возможно.  И рекомендовать обратиться можно
разве что привязываясь к ПО (ядру, в первую очередь).

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] XFS filesystem crash

[info]

20 Декабрь 2003 23:59, Vitaly Lipatov написал:> On 19 Декабрь 2003 11:17, info wrote:> > Виталий, у меня из головы не шли Ваши накрытия рейзера -> > потому как сам на нем сижу... Вот такой вопрос - а ядро у> > Вас какое? Оригинальное c kernel.org или нет? Какие патчи?> > И, главное, если ли среди них low-latency sheduler? Дело в> > том, что эта штука дописывает свои куски в коды всех> > основных файловых систем (ext2/ext3/reiser); причем на ядре> > 2.4.23 патч у меня в двух местах  провалился, и не> > где-нибудь, а на fs/inode.c и fs/buffer.c. А занимается> > она, как известно, тем, что целенаправленно тормозит в том> > числе и работу с файловой системой ради качества звука. Не> > в ней ли дело?>> Дело в том, что это давно уже идёт (наверное, изначально), с> разными ядрами и прочее. С low-latency и без него. Ядра я> всегда использую из Сизифа уже собранные.
Я для своих машин ядра _ВСЕГДА_ собираю сам. Выкидывая при этом из конфигурации то, что не используется. Например, если у меня на сервере нет (и не предвидится) bluetooth-а, то на кой хрен мне там блютуфовские модули? Или Amateur Radio? И если у меня на машине nVidia-вские видеоплаты, то на кой поддержка всех остальных? И если я не использую JFS, XFS, ext3 и даже ext2 - то я и их из конфигурации выбрасываю. А уж про поддержку различных чипсетов материнских плат я уж и не говорю...

"Конфигурим что имеем, а чего не имеем - того отнюдь не конфигурим".
Да, а то, что есть - не модулями, а прямо в ядро. На серверах у меня даже поддержка модулей отключена; до недавнего времени так же работали и дектопы, и только переход по на ALSA, применение bcrypt, да еще покупка видеокамер Creative proEx для видеоконференций потребовали модули включить.
Кстати, рейзер - как основная для меня файловая система - у меня в ядре; в ALTовских же ядрах он, насколько я помню, идет модулем... Может, в этом Ваша проблема? 
Вообще, для серверов и тем более файрволлов монолитное ядро без модулей, IMHO, вообще должно быть аксиомой.
Готовое ядро - это, IMHO, для конечных "коробочных" покупателей. Но, думаю, все здесь присутствующие обладают достаточной квалификацией, чтобы собрать себе ядро под себя.
Может, это подход несколько параноидальный, но вот практика показывает: за 4 года на 7-ми машинах - ни одного случая потери данных по вине файловой системы. 
Георгий

[sisyphus] Re: hardware@ wanted (was: XFS filesystem crash)

[Anton Farygin]

On Mon, Dec 22, 2003 at 10:16:10AM +0200, Michael Shigorin wrote:
> On Mon, Dec 22, 2003 at 03:22:12AM +0300, Денис Смирнов wrote:
> >  >>> PS: ха-ачу hardware@altlinux.ru! ;-)
> >  >> Я тоже :)
> >  > 2 team: во избежание регулярных (при этом полезных) офтопиков --
> >  > давайте-ка возьмем да и сделаем.  А то придется @linux.kiev.ua
> >  > поднимать, а там и так очередь.
> > Кроме того одной очень полезной функцией этой рассылки (и
> > народа там обитающего) может быть составление нормального HCL.
> > Лично мне такого документа _очень_ не хватает.
> 
> О чем и речь.
> 
> Вообще цель каждого хорошего ресурса (в т.ч. рассылки) --
> концентрировать аудиенцию (и, соотв., информацию) по выделенным и
> определенным темам с целью достижения хорошего SNR.
> 
> Пока "железные" вопросы обсуждаются в софтово-социальных
> рассылках (devel@, sisyphus@, community@) -- собирать результаты
> трудно, если вообще возможно.  И рекомендовать обратиться можно
> разве что привязываясь к ПО (ядру, в первую очередь).


Сегодня/завтра будет.

Rgds,
Rider

Re: [sisyphus] Re: XFS filesystem crash

[led]

В сообщении от Пятница 19 Декабрь 2003 23:00 Денис Смирнов написал(a):
> On Fri, Dec 19, 2003 at 06:51:35PM +0200, Led wrote:
>  >>Для надёжности лучше, IMHO, вложить эти же деньги во внешний массив, с
>  >>отдельным источником питания и отдельным UPS, особенно если речь идёт о
>  >>больших объёмах и SCSI-дисках.
>  >>RAID 1 хорош в первую очередь _производительностью_, правильная
>  >> реализация может на чтении работать так же быстро, как и RAID 0.
>  >
>  > Неужели? С какой это стати RAID1 может быть таким же быстрым, как RAID0?
>  > AFAIK при правильной организации RAID5 значительно быстрее RAID1 и
>  > немного уступает RAID0.
>
> При чтении можно делать то же самое, что делается в случае stripe
> (распределять разные запросы на чтение к разным устройствам), таким
> образом выигрывая _и_ на seek, _и_ на пропускной способности. То есть,
> теоретически, можно достичь даже большей скорости чем у RAID 0 (правда я
> сомневаюсь что реально это делает хотя бы кто-нибудь). Особенно хороший
> выигрыш это даст на IDE (при умной реализации).

Сорри, читал невнимательно :( Если только на чтении, то скорее всего Вы правы 
(при умной реализации:)). Вот только в чём тогда смысл зеркалирования, если 
данные будут читаться поочерёдно с каждого диска?

>
> RAID 5 требует для каждой операции записи как минимум 2 операции чтения
> (сектора в который пишем и сектора с контрольной суммой) и две операции
> записи. В отличии от двух операций записи для зеркала.
>
>  >> Поэтому связка RAID
>  >> 0+1 видится мне оптимальной для массивов IDE-дисков. Для SCSI это
>  >> слишком дорого и неэффективно, IMHO.
>  >
>  > Зеркалирование на IDE вобще себя не оправдывает... По крайней мере не
>  > видел IDE RAID с автовосстановлением.
>  > А в этом случает проще, надёжнее и дешевле периодический бэкап.
>
> Backup необходим в любом случае, это аксиома. В не зависимости от уровня
> защищённости.
Речь не об этом... Есть ли аппаратные IDE RAID1  восстановлением в фоновом 
режиме? Если нет, то чем тогда восстановление отличается от восстановления из 
бэкапа?

>
>  >> А, да, ещё одно применение -- когда на сервер ставится только 2 харда.
>  >> По финансовым соображениям. Тогда выбора нет -- только RAID 1.
>  >
>  > По финансовым соображениям в таком случае ИМХО следует использовать
>  > обычные бэкапы.
>  > А если нужна надёжность+быстрое(прозрачное) восстановление после сбоя,
>  > тогда "финансовые соображения" должны потесниться...
>  > Не бывает "так же надёжно, но в два раза дешевле"....
>
> Зато бывают разные уровни важности, надёжности, и.т.д. Наличие backup'а,
> IMHO, это настолько естественная вещь, что о факте её присутствия даже
> говорить смысла нет, говорить можно разве что о технологиях и политике
> резервного копирования.
>
> /me радуется LVM'овским snapshot'ам, и своим надеждам на то, что скоро они
> будут применимы для этой цели.

Led.

[sisyphus] Re: XFS filesystem crash

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 1104 bytes --]

On Mon, Dec 22, 2003 at 12:08:16PM +0300, info wrote:
> Вообще, для серверов и тем более файрволлов монолитное ядро без
> модулей, IMHO, вообще должно быть аксиомой.

Слишком дорого.

> Готовое ядро - это, IMHO, для конечных "коробочных"
> покупателей. Но, думаю, все здесь присутствующие обладают
> достаточной квалификацией, чтобы собрать себе ядро под себя.

Большинство присутствующих здесь в таком виде знают, что тратить
время на пересборку -- это циничное убиение этого самого времени
и что vsu@ все равно обладает _большей_ квалификацией по теме.

А я сейчас вообще зачастую склонен зачислять собирателей ядер в
пионеры, если они не могут внятно мотивировать _необходимость_
использования рабочего времени на это.  К сожалению, обычно
именно не могут.

> Может, это подход несколько параноидальный, но вот практика
> показывает: за 4 года на 7-ми машинах - ни одного случая потери
> данных по вине файловой системы. 

Кстати, rfs модулем/нет -- это пофиг.  А вот с UPS/без -- очень
даже относится.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] Re: XFS filesystem crash

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 541 bytes --]

* Michael Shigorin <mike@osdn.org.ua> [031222 12:49]:
> А я сейчас вообще зачастую склонен зачислять собирателей ядер в
> пионеры, если они не могут внятно мотивировать _необходимость_
> использования рабочего времени на это.  К сожалению, обычно
> именно не могут.
Я могу.  Моё аццкое hell-smp отличается от std-smp только тем,
что ext2 в моулях, а не статикой ;-)

-- 
Regards, Sir Raorn.
-------------------
Если Вы не будете вообще ничего качать,
то у Вас никогда не будет никакого признака
чего бы то ни было :-)
		-- zerg in sisyphus@

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] Re: XFS filesystem crash

[Yury Aliaev]

Michael Shigorin wrote:

>>Вот такой вопрос - а ядро у Вас какое?  Оригинальное c
>>kernel.org или нет?
>>
> 
> А что, тут есть самоубийцы, готовые сидеть на этой бочке??


Когда надо выплыть, бочка -- не последнее дело :) Бывают (редко) 
ситуации, в которых оно оказывается полезным, например -- когда какая-то 
шелезяка отказывается работать или глючит страшно, то имеет смысл 
попробовать, может на ванилине оно заработает.

[sisyphus] Re: XFS filesystem crash

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 657 bytes --]

On Mon, Dec 22, 2003 at 12:57:20PM +0300, Alexey I. Froloff wrote:
> > А я сейчас вообще зачастую склонен зачислять собирателей ядер в
> > пионеры, если они не могут внятно мотивировать _необходимость_
> > использования рабочего времени на это.  К сожалению, обычно
> > именно не могут.
> Я могу.  Моё аццкое hell-smp отличается от std-smp только тем,
> что ext2 в моулях, а не статикой ;-)

Ну тут-то все в курсе, что это из-за Кривово Мандраковского
Иинсталятора (tm) :-)

Посему это как раз понятно, хотя все равно -- why bother, если
можно bootparam'ами.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[sisyphus] Re: XFS filesystem crash

[Michael Shigorin]

On Mon, Dec 22, 2003 at 01:47:06PM +0300, Yury Aliaev wrote:
> >>Вот такой вопрос - а ядро у Вас какое?  Оригинальное c
> >>kernel.org или нет?
> >А что, тут есть самоубийцы, готовые сидеть на этой бочке??
> Бывают (редко) ситуации, в которых оно оказывается полезным,
> например -- когда какая-то шелезяка отказывается работать или
> глючит страшно, то имеет смысл попробовать, может на ванилине
> оно заработает.

Что-то давно такого не припомню.  Вот обратного -- сколько угодно.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [sisyphus] Re: XFS filesystem crash

[info]

22 Декабрь 2003 12:46, Michael Shigorin написал:
> On Mon, Dec 22, 2003 at 12:08:16PM +0300, info wrote:
> > Вообще, для серверов и тем более файрволлов монолитное ядро
> > без модулей, IMHO, вообще должно быть аксиомой.
>
> Слишком дорого.

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

>
> > Готовое ядро - это, IMHO, для конечных "коробочных"
> > покупателей. Но, думаю, все здесь присутствующие обладают
> > достаточной квалификацией, чтобы собрать себе ядро под
> > себя.
>
> Большинство присутствующих здесь в таком виде знают, что
> тратить время на пересборку -- это циничное убиение этого
> самого времени и что vsu@ все равно обладает _большей_
> квалификацией по теме.

Я прикинул - у меня это занимает часа два в год... Может, 
четыре. Но зато у меня ни разу не было ситуаций наподобие той, 
которая тут недавно обсуждалась -  имеется в виду ветка 
[sisyphus] kernel-image-std-smp@2.4.22-alt13

Вопрос: на что тратится больше времени, на прогонку компилятором 
по отлизанному .config, или на возню вот с такими проблемами?

>
> А я сейчас вообще зачастую склонен зачислять собирателей ядер
> в пионеры, если они не могут внятно мотивировать
> _необходимость_ использования рабочего времени на это.  К
> сожалению, обычно именно не могут.

Необходимость? Запросто. Например, безопасность. Я _абсолютно_ 
уверен, что никто и никогда, ни на какой машине, не подгрузит 
какой-нибудь модуль, который я там не хочу видеть, и не 
запустит какой-нибудь сервис, которого быть не должно.  
Например, nfs-сервер на рабочей станции, открывающий содержимое 
home всей локалке.  А то и не только локалке...

Георгий

[sisyphus] custom kernels (was: XFS filesystem crash)

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 2293 bytes --]

On Mon, Dec 22, 2003 at 02:12:29PM +0300, info wrote:
> > > Вообще, для серверов и тем более файрволлов монолитное ядро
> > > без модулей, IMHO, вообще должно быть аксиомой.
> > Слишком дорого.
> Что дорого? Выпускать дистрибутивы с набором монолитных ядер
> под разные виды железа? Согласен, это безумие.

Чистой воды.

> Но вот собрать свое монолитное ядро под свой сервер, а тем
> более файрволл - прямая обязанность админа. 

Повторюсь: без мотивации у меня такой админ помещается в очередь
за дверь.  Вот посмотрю, переучиваемый или нет...

> Я прикинул - у меня это занимает часа два в год... Может,
> четыре. Но зато у меня ни разу не было ситуаций наподобие той,
> которая тут недавно обсуждалась -  имеется в виду ветка
> [sisyphus] kernel-image-std-smp@2.4.22-alt13

Хех.  Не верю, что не было ни разу более других ситуаций.

> Вопрос: на что тратится больше времени, на прогонку
> компилятором по отлизанному .config, или на возню вот с такими
> проблемами?

На решение проблемы в апстриме время по определению тратится
более эффективно.  ПОтому что потом достаточно взять то, что
считаешь good enough, и не парить репу.

Hint: что Вы делали с последним local root?  Правильно, тратили
время.  А шансов огрести грабли при этом что -- не было?

> > А я сейчас вообще зачастую склонен зачислять собирателей ядер
> > в пионеры, если они не могут внятно мотивировать
> > _необходимость_ использования рабочего времени на это.  
> Необходимость? Запросто. Например, безопасность. Я _абсолютно_
> уверен, что никто и никогда, ни на какой машине, не подгрузит
> какой-нибудь модуль, который я там не хочу видеть, и не
> запустит какой-нибудь сервис, которого быть не должно.

А я бы не был так уверен, пока есть возможность писать в
/dev/kmem; даже не читая bugtraq.  А админ, который в чем-то
_абсолютно_ уверен -- тоже, кстати, вызывает подозрения в
профпригодности, Вы уж не обессудьте. (сам такое прошел)

Это раз.

Два -- посмотрите пакет kernel-fix-security и убедитесь, что
_все_ патчи (в эквиваленте) у Вас приложены.  Иначе все эти
разговоры про секурити самосбора -- самодур.

И это ведь еще не все моменты, из-за которых building custom
kernels considered harmful в общем случае.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] Re: XFS filesystem crash

[Serge Ryabchun]

В сообщении от Пт 19 Дек 2003 23:00 Денис Смирнов написал(a):
> On Fri, Dec 19, 2003 at 06:51:35PM +0200, Led wrote:
>  >>Для надёжности лучше, IMHO, вложить эти же деньги во внешний массив, с
>  >>отдельным источником питания и отдельным UPS, особенно если речь идёт о
>  >>больших объёмах и SCSI-дисках.
>  >>RAID 1 хорош в первую очередь _производительностью_, правильная
>  >> реализация может на чтении работать так же быстро, как и RAID 0.
>  >
>  > Неужели? С какой это стати RAID1 может быть таким же быстрым, как RAID0?
>  > AFAIK при правильной организации RAID5 значительно быстрее RAID1 и
>  > немного уступает RAID0.
>
> При чтении можно делать то же самое, что делается в случае stripe
> (распределять разные запросы на чтение к разным устройствам), таким
> образом выигрывая _и_ на seek, _и_ на пропускной способности. То есть,
> теоретически, можно достичь даже большей скорости чем у RAID 0 (правда я
> сомневаюсь что реально это делает хотя бы кто-нибудь). Особенно хороший
> выигрыш это даст на IDE (при умной реализации).

Делает, read 136Mbs на 4-х дисках в RAID10, при том что на одиночном только
45. 

--
Serge Ryabchun <sr@osdn.org.ua>

Re: [sisyphus] Re: XFS filesystem crash

[Yury Aliaev]

Michael Shigorin wrote:

> А я сейчас вообще зачастую склонен зачислять собирателей ядер в
> пионеры, если они не могут внятно мотивировать _необходимость_
> использования рабочего времени на это.  К сожалению, обычно
> именно не могут.

Единственная вещь, из-за кторой я собираю дома ядро сам -- supermount, 
отсутствие коего вызывает у меня жуткий перерасход нервных клеток. Хотя, 
если его-таки стали включать в стандартные альтовские ядра, то я -- пас 
(про всякие мультимедийные патчи вроде lowlattency я знаю, что да).

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Mon, Dec 22, 2003 at 03:54:14PM +0200, Serge Ryabchun wrote:

 > > При чтении можно делать то же самое, что делается в случае stripe
 > > (распределять разные запросы на чтение к разным устройствам), таким
 > > образом выигрывая _и_ на seek, _и_ на пропускной способности. То есть,
 > > теоретически, можно достичь даже большей скорости чем у RAID 0 (правда я
 > > сомневаюсь что реально это делает хотя бы кто-нибудь). Особенно хороший
 > > выигрыш это даст на IDE (при умной реализации).
 > Делает, read 136Mbs на 4-х дисках в RAID10, при том что на одиночном только
 > 45. 

Какой контроллер?

-- 
С уважением, Денис

http://freesource.info

Re: [sisyphus] Re: XFS filesystem crash

[Serge Ryabchun]

В сообщении от Вт 23 Дек 2003 07:27 Денис Смирнов написал(a):
> On Mon, Dec 22, 2003 at 03:54:14PM +0200, Serge Ryabchun wrote:
>  > > При чтении можно делать то же самое, что делается в случае stripe
>  > > (распределять разные запросы на чтение к разным устройствам), таким
>  > > образом выигрывая _и_ на seek, _и_ на пропускной способности. То есть,
>  > > теоретически, можно достичь даже большей скорости чем у RAID 0 (правда
>  > > я сомневаюсь что реально это делает хотя бы кто-нибудь). Особенно
>  > > хороший выигрыш это даст на IDE (при умной реализации).
>  >
>  > Делает, read 136Mbs на 4-х дисках в RAID10, при том что на одиночном
>  > только 45.
>
> Какой контроллер?

LSI одноканальник какой-то 320, а, какой-то, вот рядом сгоревший такой же 
лежит - LSI MegaRAID UltraSCSI 320-1, RAID 0, 1, 10, 5 и 50.

Re: [sisyphus] Re: XFS filesystem crash

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 504 bytes --]

* Serge Ryabchun <sr@osdn.org.ua> [031223 11:39]:
> LSI одноканальник какой-то 320, а, какой-то, вот рядом
> сгоревший такой же лежит - LSI MegaRAID UltraSCSI 320-1, RAID
> 0, 1, 10, 5 и 50.
RAID 50 это два RAID 5 в stripe?

-- 
Regards, Sir Raorn.
-------------------
Поскольку hasher проектировался прежде всего для пересборки большого числа
пакетов (полученных из разных источников) по одному разу, использовать его
для ускоренной пересборки одного пакета много раз будет непросто.
		-- ldv in devel@

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] Re: XFS filesystem crash

[Serge Ryabchun]

В сообщении от Вт 23 Дек 2003 10:50 Alexey I. Froloff написал(a):
> * Serge Ryabchun <sr@osdn.org.ua> [031223 11:39]:
> > LSI одноканальник какой-то 320, а, какой-то, вот рядом
> > сгоревший такой же лежит - LSI MegaRAID UltraSCSI 320-1, RAID
> > 0, 1, 10, 5 и 50.
>
> RAID 50 это два RAID 5 в stripe?

ага, у 320-2 еще и RAID15, те 5+1, и, кстати на прозвучавший ранее
вопрос - rebuild RAID1 начинается сразу же после первого обращения
к винту, у адаптеков сразу же после втыкание второго винта.

Re: [sisyphus] Re: XFS filesystem crash

[Serge Ryabchun]

В сообщении от Пт 19 Дек 2003 11:30 Michael Shigorin написал(a):
> On Fri, Dec 19, 2003 at 04:09:24AM +0300, Денис Смирнов wrote:
> > BadBlock == потеря данных в одном блоке, причём, на современных
> > хардах, незаметная для приложения (кроме как по потере этих
> > самых данных). Вещь достаточно редкая, но встречающаяся, увы.
>
> Денис, что-то Вы странное расказываете.  Редкий блок вот так
> сразу и долетит за середину диапазона вероятности читаемости;
> современные винты занимаются ремапом не когда уже поздно, а когда
> оная читаемость падает ниже порога.
>
> JAIH

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

Re: [sisyphus] Re: XFS filesystem crash

[Alexey Morozov]

On Mon, Dec 22, 2003 at 05:16:17PM +0300, Yury Aliaev wrote:
> Единственная вещь, из-за кторой я собираю дома ядро сам -- supermount, 
> отсутствие коего вызывает у меня жуткий перерасход нервных клеток. Хотя, 
> если его-таки стали включать в стандартные альтовские ядра, то я -- пас 
> (про всякие мультимедийные патчи вроде lowlattency я знаю, что да).
Не стали. "Давайте собирать вместе" :-).

На самом деле, мой aws-up flavour - это такая Athlon'ная станция с
супермаунтом, отсуствием всякой ненужной мне фигни :-), и 

%ghost /boot/initrd-%kversion-%flavour-%krelease.img

вместо того ужаса, который в post-script'ах для std-up :-))

[sisyphus] Re: XFS filesystem crash

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 253 bytes --]

On Tue, Dec 23, 2003 at 09:41:28PM +0600, Alexey Morozov wrote:
> %ghost /boot/initrd-%kversion-%flavour-%krelease.img
> 
> вместо того ужаса, который в post-script'ах для std-up :-))

Пожалуйста, опишите ужас в post-script'ах (предложите исправление).

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Tue, Dec 23, 2003 at 10:31:06AM +0200, Serge Ryabchun wrote:

 > LSI одноканальник какой-то 320, а, какой-то, вот рядом сгоревший такой же 
 > лежит - LSI MegaRAID UltraSCSI 320-1, RAID 0, 1, 10, 5 и 50.

Ой. А отчего сгорел?

-- 
С уважением, Денис

http://freesource.info

Re: [sisyphus] Re: XFS filesystem crash

[Serge Ryabchun]

В сообщении от Ср 24 Дек 2003 08:51 Денис Смирнов написал(a):
> On Tue, Dec 23, 2003 at 10:31:06AM +0200, Serge Ryabchun wrote:
>  > LSI одноканальник какой-то 320, а, какой-то, вот рядом сгоревший такой
>  > же лежит - LSI MegaRAID UltraSCSI 320-1, RAID 0, 1, 10, 5 и 50.
>
> Ой. А отчего сгорел?

А кто ж его знает ;-),  "системный блок вы заплевали, на плату пролили 
компот", горит всё от 8-ми долларового адаптека образца 96 года до свежего 
инфотренда за две с половиной штуки зеленых денег. С месяц назад видел 
оплавившиеся микросхемы на двух винтах в зеркале, сгорел контроллер и потянул
винты ;-))), сейчас туда поставили в зеркало две корзинки с RAID5, всё ж 
шансы, что хоть что то выживет есть.

[sisyphus] Re: XFS filesystem crash

[Денис Смирнов]

On Thu, Dec 25, 2003 at 10:26:34AM +0200, Serge Ryabchun wrote:

 > А кто ж его знает ;-),  "системный блок вы заплевали, на плату пролили 
 > компот", горит всё от 8-ми долларового адаптека образца 96 года до свежего 
 > инфотренда за две с половиной штуки зеленых денег. С месяц назад видел 
 > оплавившиеся микросхемы на двух винтах в зеркале, сгорел контроллер и потянул
 > винты ;-))), сейчас туда поставили в зеркало две корзинки с RAID5, всё ж 
 > шансы, что хоть что то выживет есть.

Ужасы-то какие... 

-- 
С уважением, Денис

http://freesource.info

Re: [sisyphus] Re: XFS filesystem crash

[Alexey Morozov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Dec 23, 2003 at 07:06:17PM +0300, Alexey Tourbin wrote:
> > %ghost /boot/initrd-%kversion-%flavour-%krelease.img
> > вместо того ужаса, который в post-script'ах для std-up :-))
> Пожалуйста, опишите ужас в post-script'ах (предложите исправление).
%postun                                                                         
rm -f /boot/initrd-%{kversion}-%{flavour}-%{krelease}.img

заменено на

%ghost /boot/initrd-%{kversion}-%{flavour}-%{krelease}.img

насколько я могу судить, работает. Ну и плюс, конечно, я так до конца и не
понял, зачем принудительно выставлять линки. То есть, понятно, что делается,
непонятно, что в bootloaders-utils не работает, из-за чего приходится так
изгаляться.

# later - fix please bootloader-utils package
ln -snf vmlinuz-%{kversion}-%{flavour}-%{krelease} /boot/vmlinuz-up
ln -snf vmlinuz-%{kversion}-%{flavour}-%{krelease} /boot/vmlinuz
ln -snf initrd-%{kversion}-%{flavour}-%{krelease}.img /boot/initrd-up.img
ln -snf initrd-%{kversion}-%{flavour}-%{krelease}.img /boot/initrd.img



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/+M9eX5DZdJn19V0RAu45AKCj6OV6jaa2UiBu1O6ZiWG8tLAlYQCfSfRb
UNS285sr0EjwRgm4wZMAT28=
=eZ03
-----END PGP SIGNATURE-----