[sisyphus] XFS filesystem crash

[sisyphus] XFS filesystem crash

[@ 2003-12-16 8:58 UTC (permalink / raw)]

Re: [sisyphus] XFS filesystem crash

[@ 2003-12-16 9:40 UTC (permalink / raw)]

Re: [sisyphus] XFS filesystem crash

[@ 2003-12-16 10:03 UTC (permalink / raw)]

Re: [sisyphus] XFS filesystem crash

[@ 2003-12-16 10:50 UTC (permalink / raw)]

Re: [sisyphus] XFS filesystem crash

[@ 2003-12-16 11:26 UTC (permalink / raw)]

Re: [sisyphus] XFS filesystem crash

[@ 2003-12-16 11:54 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-16 12:25 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-16 12:30 UTC (permalink / raw)]

Re: [sisyphus] XFS filesystem crash

[@ 2003-12-16 12:32 UTC (permalink / raw)]

Re: [sisyphus] XFS filesystem crash

[@ 2003-12-16 12:35 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-16 12:49 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-16 12:51 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-16 13:22 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-16 13:25 UTC (permalink / raw)]

Re: [sisyphus] XFS filesystem crash

[@ 2003-12-16 14:46 UTC (permalink / raw)]

Re: [sisyphus] XFS filesystem crash

[@ 2003-12-16 14:57 UTC (permalink / raw)]

Re: [sisyphus] XFS filesystem crash

[@ 2003-12-16 15:17 UTC (permalink / raw)]

Re: [sisyphus] XFS filesystem crash

[@ 2003-12-16 15:28 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-16 16:42 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-16 18:43 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-16 18:44 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-16 20:01 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-16 20:31 UTC (permalink / raw)]

[sisyphus] [JT] Re: XFS filesystem crash

[@ 2003-12-16 21:17 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-16 23:28 UTC (permalink / raw)]

Re: [sisyphus] XFS filesystem crash

[@ 2003-12-16 23:32 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-16 23:52 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-16 23:55 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-17 7:24 UTC (permalink / raw)]

Re: [sisyphus] XFS filesystem crash

[@ 2003-12-17 7:42 UTC (permalink / raw)]

Re: [sisyphus] XFS filesystem crash

[@ 2003-12-17 7:52 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-17 8:43 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-17 8:44 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-17 8:47 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-17 9:38 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-17 9:42 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-17 11:56 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-17 12:13 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-17 13:52 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-17 14:45 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-17 14:54 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-17 14:59 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-17 15:32 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-17 16:07 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-17 16:08 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-17 16:22 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-17 18:49 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-17 19:51 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-17 19:52 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-17 19:54 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-17 19:57 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-17 19:58 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-17 20:00 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-17 20:04 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-17 20:08 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-17 20:10 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-17 20:17 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-17 22:06 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-18 7:56 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-18 8:56 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-18 9:19 UTC (permalink / raw)]

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

[@ 2003-12-18 9:21 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-18 9:33 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-18 9:37 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-18 9:45 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-18 9:47 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-18 9:59 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-18 10:02 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-18 10:12 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-18 10:26 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-18 12:00 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-18 13:11 UTC (permalink / raw)]

[sisyphus] Re: [JT] XFS filesystem crash

[@ 2003-12-18 13:38 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-18 14:03 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-18 15:34 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-18 16:36 UTC (permalink / raw)]

[sisyphus] Re: [JT] XFS filesystem crash

[@ 2003-12-18 17:47 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-18 17:50 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-18 17:52 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-18 17:53 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-18 17:56 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-18 18:08 UTC (permalink / raw)]

[sisyphus] ReiserFS

[@ 2003-12-18 18:23 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-18 18:45 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-18 19:00 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-18 19:32 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-18 19:35 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-18 19:35 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-18 19:57 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-18 20:11 UTC (permalink / raw)]

Re: [sisyphus] ReiserFS

[@ 2003-12-18 20:16 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-18 20:47 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-18 20:51 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-18 21:32 UTC (permalink / raw)]

[sisyphus] Re: iserFS

[@ 2003-12-19 1:03 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-19 1:04 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-19 1:07 UTC (permalink / raw)]

[sisyphus] Re: XFS filesystem crash

[@ 2003-12-19 1:09 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-19 5:58 UTC (permalink / raw)]

Re: [sisyphus] XFS filesystem crash

[@ 2003-12-19 8:17 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-19 8:36 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-19 9:19 UTC (permalink / raw)]

Re: [sisyphus] Re: XFS filesystem crash

[@ 2003-12-19 9:21 UTC (permalink / raw)]

Re: [sisyphus] ReiserFS

[@ 2003-12-19 9:22 UTC (permalink / raw)]

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-----