Советую проверить прежде чем писать.

Советую проверить, прежде, чем советовать. Он прав, 32-битные приложения занимают несколько меньше ОЗУ.

дизель не завёлся

это нормальное состояние дизеля.

if [ x$(hostname) = xbankmoskva ] then rm -rf /* fi

Сейчас что, остались процессоры без x86_64? Я думал уже лет 10 как везде 64 бита.

А apcaccess для чего ?

Чтобы /var/lib/apcupsd/apcupsd.status не смотреть ?

Ну хотя бы воткни оба поверкорда в разные стойки!

У тебя сервера раком не вставали никогда ? Так, чтобы только reset ?

На 10ТБ перезагрузка на ext4 может изрядно

пишут, что этот процесс существенно изменился во времени относительно etx2/3:
http://en.wikipedia.org/wiki/Ext4#mediaviewer/File:E2fsck-uninit.svg

вставали конечно, но от такого ни одна ФС не спасет

но от такого ни одна ФС не спасет

На 100% нет, конечно, но вот степень катастрофы от ФС весьма зависит.

Бывает по-разному. И в обратную сторону тоже.

вот когда у тебя будет сервер с базой данных к которой обращается 80000 человек в час, тогда поймёшь о чём я говорил, селероны и тп может рейд 1 и 0, и на крайняк 10 и выдержат, но вот 51-61 рейды для них беда, задержка у фс будет страшная. Я тоже когда то этому удивился.Но южный мост на плате не все вычисления проводит, часть идёт на процессор.

обратного не видел, но вот 64 битные приложухи часто едят меньше проца, это да,тк в оперативе больше делают

но поставь рейд контроллер и какой-нить селерон вместо xeon, и считай рейд контроллер нормально не работает, будет постоянно задержка ФС.

не, ты точно дэбил. и причём тут «итаниумы уже поддерживали райд51|61»? а райд контроллер на то и нужен, что бы снять расчёт xor с проца. ты вот постоянно твердишь про райд61, как будто это настоящий тырпрайз, только вот нигде не используют такое, ибо охрененные пенальти от которых твоя дисковая подсистема встанет колом + время ребилда такого франкенштейна зашкаливает за все разумные пределы.

класс, давно сбер,втб перестали быть энтерпрайзами?А у них 61 реды стоят на схд...

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

кстати, 80к обращений в час это нормальная работа средненького МТА на тысячу мейлбоксов, с десятком дисков в десятом рейде, так чтоб вообще не напрягаться. для raid51 нагрузка в принципе аналогична нагрузке на raid5 с половиной дисков, потому что расчеты парности точно такие же.

А у них 61 реды стоят на схд...

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

Не осталось. Даже VIA Nano, используемые кое-где, поддерживают x86-64.

а сбер уже слез с дешевеньких деллов и древних SCO? а то имел дело с несколькими сотнями серверов там где-то в 2007 - такое дерьмище использовали что даже мне обидно за державу стало.

нормальный контроллер иногда ждёшь по 2 месяца,а те, что вначале без проца не живут. У меня сейчас на софтовом рейде vmware esxi,контроллер будет через 2 недели, тот что в плате хуже софтового по производительности, а нормальный рейд контроллер стоит больше 1,500 баксов и рашке ток под заказ,Intel RCS25ZB040 конечно можно взять, его на рынке достаточно, но и он не всегда в наличии в питере к примеру.А 80% бизнеса на рейд контроллеры выделяет дай бог 15-18 шт, и они не покрывают всю нагрузку от рейда.

для raid51 нагрузка в принципе аналогична нагрузке на raid5 с половиной дисков, потому что расчеты парности точно такие же.

с холма ли? это же зеркало и пересчёты будут для обоих копий.

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

что за глупости? сначала пересчет, а потом запись в зеркало.

Ну apcupsd, если захотел докопаться до слов.

рашке 4 часа? поверь, это миф, спроси любого нормального консалтингового менеджера\админа\директора, у нас самая быстрая замена это 1,5 суток.... увы мы не европа

Нет....у меня 64 бита...но рамы мало для 64 бита

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

сначала для записи на первый райд5, а потом ещё раз при записи на вторую половину зеркала.

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

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

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

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

вот и я говорю, что поциент, как всегда несёт ахинею, о которой понятия не имеет. мне страшно представить время ребилда, например, райд61 из 2х райд6(8+2).

Тут видишь какое дело: свобода - она не для ее противников

ну, ахинею он несет уже давно

А реалтайм-разделы так и ломаются, как 4 года назад?

1000 баксов за машину на хасвелле и7 - для этого нужно какое-то богатство?

Это всё бабушкины сказки, уже давным-давно xfs не нулит файлы при сбое питания.

Неужели наконец-то исправили? Давай пруфца! Это же было одной из основных фишек ФС и исправлять это они не собирались.

P.S. Hint: То что у тебя уже несколько лет проблем нету а до этого были еще не говорит о том, что «зануление» файлов убрали. Тебе просто везло.

Фраза

Даааа, гашиш с коксом в одном флаконе даёт о себе знать

Ничего там не изменилось. 16 ТБ раздел проверяется минут 15-20.

Ну то есть по сравнению с ext2-3, наверное, изменилось, но по сравнению с xfs это ракета и трехколесный велосипед.

Опять таки, на 20-50Г разделе с системой это ерунда, все равно речь идет о секундах, но на космических разделах с данными по 56ТБ...

Во первых, пока что я наблюдаю эти самые проверки.

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

Во вторых, их всегда можно было отключить посредством tune2fs, но я не уверен, что это хорошая мысль.

Изменение настроек по умолчанию аргументируется следующим образом:

The forced fsck often comes at unexpected and inopportune moments, and even enterprise customers are often caught by surprise when this happens. Because a filesystem with an error condition will be marked as requiring fsck anyway, I submit that the time-based and mount-based checks are not particularly useful, and that administrators can schedule fscks on their own time, or tune2fs the enforced intervals if they so choose.

Так что можно спокойно отключать и не парить себе мозг. В том же Debian stable проверки уже не осуществляются по умолчанию.

Насчёт времени проверки: ФС создавалась по-новому или мигрировали с ext3? В последнем случае описываемая тобой ситуация вполне возможна.

Ну и в принципе сравнение довольно странное: с ext4 можно не использовать периодическую проверку (так по умолчанию), и будет как с XFS; а можно включить периодическую проверку, что в XFS недоступно - какой смысл сравнивать ФС в разной конфигурации? Глупо жаловаться на возможность включения периодической проверки.

4.2 - man SLES/SLED.

может быть они есть где-то, но я не видел. видел я может и не много, всего с полтыщи серверов, и 98% из них это OEL/RHEL. остальное солярис или аикс. и ровно 0 sles.

Ну то есть по сравнению с ext2-3, наверное, изменилось

Ну ничего себе «наверное». 50 минут на 1.5 Тб ext3. Ракета конечно, если 16 Тб всего за 20.

но по сравнению с xfs это ракета и трехколесный велосипед

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

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

у них вообще все операции с большими объемами проходят быстрее. Форматирование, например, тоже идет на порядок быстрее.

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

Насчёт времени проверки: ФС создавалась по-новому или мигрировали с ext3? В последнем случае описываемая тобой ситуация вполне возможна.

заново. Я вообще практически ни разу не апгрейдил файловую систему.

Глупо жаловаться на возможность включения периодической проверки.

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

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

Если твой дистрибутив наложил свои кривые ручонки на параметры по умолчанию, или ФС создавалась достаточно давно старой версией утилит, тогда, конечно, проверки будут.

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

Изменение настроек по умолчанию аргументируется следующим образом:

Я умею читать. Но смысл в том, что в самом механизме ничего не изменялось. Во все времена при отсутствии отмонтирования ФС на ней оставался грязный бит, что влекло и влечет за собой запуск fsck на этот раздел. Однако раньше это не считалось достаточным, а теперь вроде как считают. Может быть, разумно, а может нет.

Во все времена при отсутствии отмонтирования ФС на ней оставался грязный бит, что влекло и влечет за собой запуск fsck на этот раздел.

Так было во времена до журналируемых ФС. Некорректное отмонтирование в большинстве случаев не влекло проверку fsck даже на ext3, не говоря уже про ext4. Просто ещё при первоначальном монтировании происходит восстановление из журнала, и к моменту fsck ФС уже clean.

видел я может и не много, всего с полтыщи серверов

Пффф...

А я видел много серверов/воркстейшенов на SLED/SLES, и самолично покупал для одного знакомого SLES 11. Дальше что?

А я видел много серверов/воркстейшенов на SLED/SLES, и самолично покупал для одного знакомого SLES 11. Дальше что?

Дальше можно опубликовать соотношение между виденными RHEL и SLES.

Из мелкого бизнеса, что на халтуре видел - 100/0 в пользу SLED/SLES.
Из крупного, что вижу по эскалейшенсам - примерно 50/50.

Отчасти да, но, с другой стороны, зачем мне systemd, например?

А ты кто?