Какой дистрибутив лучше установить

[Эрфеа]

Цитата (Ильменгир) »

Чувак, ты ещё забыл написать о файловой системе. Это вобще слабое место почти всех *BSD. FFS - это УГ. Но если во фрю была портирована ZFS, то ничего такого о нет-бсд я не слышал. Так шта ....

А вы смотрю такой спец по фс?!

[Ильменгир]

И чё?
"Любите ли вы FFS так, как люблю её я?"

[Эрфеа]

Цитата (Ильменгир) »

И чё?
"Любите ли вы FFS так, как люблю её я?"

вы это очем, любезнейший? моя ваша откровенно не понимать...

[Xaionaro]

Цитата (Ильменгир) »

Чувак, ты ещё забыл написать о файловой системе. Это вобще слабое место почти всех *BSD. FFS - это УГ. Но если во фрю была портирована ZFS, то ничего такого о нет-бсд я не слышал. Так шта ....

Мои два первые и последние общения с реализацией ZFS у FreeBSD закончились так:
1.) При первой же "некорректной перезагрузке" на файл-сервере потерялся теробайтный раздел с фильмами и музыкой и я не смог его восстановить (хотя в тот момент ZFS только-только появился во FreeBSD)
2.) Я пытался создать rescue disc для одного сервера на solaris на zfs... И вот когда решил загрузиться с этого диска, он не смог подцепить zfs с винчестеров, из-за того, что реализация zfs во FreeBSD слишком сильно отстаёт по версии от того, что было в том нескольколетнем solaris.

Мне от этой реализации было больше вреда, чем пользы... вернее пользы вообще небыло.

Хотя я согласен, что FFS меня дико надоел со своими проблемами. /me любитель комбинации xfs, reiserfs и ext3

[Эрфеа]

Я использую только ext3 и ext2 на флешках. Очень надёжная ФС, никогда жаловаться не приходилось.

[Xaionaro]

Цитата (Эрфеа) »

Я использую только ext3 и ext2 на флешках. Очень надёжная ФС, никогда жаловаться не приходилось.

Кроме надёжности есть тонна параметров. Например ext2 не журналируем в принципе. Но это лишь одна из кучи проблем, как и мелких, так и пары крупных. Вот, например, пара крупных минусов ext2/ext3:
1.) Нельзя расширять run-time, как например xfs (xfs_growfs). Что для серверов очень желательно.
2.) Чрезвычайно медленные ФС. Во некоторых местах использовать тупо нереально из-за этого. Возможно будущее кроется за ext4, но пока что я боюсь его использовать, ибо последний раз когда его использовал (тогда в ядре назывался ext4dev), он иногда приводил к kernel panic , у меня даже фотография сохранилась)

[Эрфеа]

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

[Xaionaro]

Цитата (Эрфеа) »

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

Например был сайт для вывода данных биллинга (с графиками и со всем сразу)... Там до меня был настроен LVM и поверх него естественно подняты все разделы. Там я очень часто применял xfs_growfs, а если бы я вместо того останавливал работу сервиса - клиенты и начальство было бы очень недовольны... Аналогично был хостинговый сервер, где нередко приходилось расширять "/var/www" там тоже начальство и клиенты были бы недовольны.

Был так же файл-сервер в одной локалке, который почему-то работая на xfs справлялся намного лучше, чем работая на ext3 (скорость отдачи файлов выше)... Но это оборудование дешёвое, т.е. проблему можно было решить вложив больше денег.

На самом деле какой смысл приводить все примеры, если на эту тему есть куча сравнительных статей и benchmark-ов?.. Мне тупо лень .

[Эрфеа]

Цитата (Xaionaro) »

На самом деле какой смысл приводить все примеры, если на эту тему есть куча сравнительных статей и benchmark-ов?.. Мне тупо лень .

Статьи статьями, а вот бенчмарки и реальный опыт (мой личный), говорит что этот прирост не так значителен, чтобы подвергать опасности данные, (если они не так важны и их не много, то лучше из вообще пихать в оперативу, тут прирост будет действительно значительный). Никто не застрахован, а восстановить данные с того же xfs шансов куда как меньше нежели из ext3.

[Xaionaro]

Цитата (Эрфеа) »

Статьи статьями, а вот бенчмарки и реальный опыт (мой личный), говорит что этот прирост не так значителен, чтобы подвергать опасности данные, (если они не так важны и их не много, то лучше из вообще пихать в оперативу, тут прирост будет действительно значительный). Никто не застрахован, а восстановить данные с того же xfs шансов куда как меньше нежели из ext3.

Да, я согласен, восстановить данные с xfs малореально, а с reiserfs вообще нереально. Но XFS у меня ещё ниразу не слетало, тем более я его применял на машинах с различными RAID. Но восстанавливаемость данных слишком сомнительный плюс, особенно когда всё всегда бекапируется. А "оперативы" 300-2000GiB обычно нет. И я тоже основываюсь обычно на собственный опыт, но статьи тем ни менее помогают получить предварительные впечатление о той или иной технологии

[Эрфеа]

Цитата (Xaionaro) »

Да, я согласен, восстановить данные с xfs малореально, а с reiserfs вообще нереально. Но XFS у меня ещё ниразу не слетало, тем более я его применял на машинах с различными RAID. Но это слишком сомнительный плюс, особенно когда всё всегда бекапируется.

Но и его прирост производительности сомнителен, раз уж нужна производительность, то надо не над фс изголяться а тратиться, для бд например шикарным вариантом будет аппаратное зеркало, естественное увеличение скорости чтения (и мягко говоря заметно больше), плюс кеш, измеряемый сотнями мегабайт собственной оперативы, при типичных для бд операциях записи очень ощутимо ускоряет запись, ну и надёжность, зеркало = избыточность и опять же горячую замену харды на такой красавице никто не отменял

[Xaionaro]

Цитата (Эрфеа) »

Но и его прирост производительности сомнителен, раз уж нужна производительность, то надо не над фс изголяться а тратиться, для бд например шикарным вариантом будет аппаратное зеркало, естественное увеличение скорости чтения (и мягко говоря заметно больше), плюс кеш, измеряемый сотнями мегабайт собственной оперативы, при типичных для бд операциях записи очень ощутимо ускоряет запись, ну и надёжность, зеркало = избыточность и опять же горячую замену харды на такой красавице никто не отменял

Во-первых кроме БД бывают графики, во-вторых как это поможет в случай файл-сервера?

И вообще ты рассматриваешь лишь одну проблему. А такую вторую проблему как лишь из тех что провёл только я, ты не рассматриваешь, а именно наращивание ФС run-time в ext2/3 невозможно.

А по поводу восстанавливаемости данных, например зачем восстанавливать данные из "/tmp", почему нельзя этот "/tmp" поднять на другой ФС?

[Эрфеа]

Ну и в догонку добавлю: где в книгах по программированию читал, что не стоит тратить время на оптимизацию кода, если это оптимизация даст предположим все-го то 5% к производительности, оптимизация может плохо сказаться на надёжности и не оправдано дорога при таком раскладе. А альтернативные фс, хотя и не совсем так, но по сути та самая оптимизация ради жалких процентов.

[Xaionaro]

Цитата (Эрфеа) »

Ну и в догонку добавлю: где в книгах по программированию читал, что не стоит тратить время на оптимизацию кода, если это оптимизация даст предположим все-го то 5% к производительности, оптимизация может плохо сказаться на надёжности и не оправдано дорога при таком раскладе. А альтернативные фс, хотя и не совсем так, но по сути та самая оптимизация ради жалких процентов.

Оооо да, программирование.. Меня уже надоело смотреть, как люди в цикле сравнивают неизменяющиеся строки и т.п. Некоторые недостатки в мозгах программистов снижают производительность иногда намного выше, чем на 5%... Но мы сейчас о другом.. Мы сейчас об ФС. И в случай работы с огромными разделами, где огромное кол-во данных, с которыми работает огромное кол-во клиентов ext3 меня неоднократно разочаровал...

Захотелось начать расписывать случаи из программирования, но понял, что это зародит ещё один холивар

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

[Эрфеа]

Цитата (Xaionaro) »

Во-первых кроме БД бывают графики, во-вторых как это поможет в случай файл-сервера?

Ну для файл сервера то ext3 ИМХО самая шикарная фс.

Цитата (Xaionaro) »

И вообще ты рассматриваешь лишь одну проблему. А такую вторую проблему как лишь из тех что провёл только я, ты не рассматриваешь, а именно наращивание ФС run-time в ext2/3 невозможно.

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

Цитата (Xaionaro) »

А по поводу восстанавливаемости данных, например зачем восстанавливать данные из "/tmp", почему нельзя этот "/tmp" например сделать на reiserfs ?

А на фига простите эту помойку на дисковой подсистеме держать?! tmpfs и в лёгкий (или точнее нереально шустрый) путь, я уже говорил про оперативу

Добавлено через 1 минуту

Цитата (Xaionaro) »

И в случай работы с огромными разделами, где огромное кол-во данных, с которыми работает огромное кол-во клиентов ext3 меня неоднократно разочаровал...

А меня нет, чтяднт?

[Xaionaro]

Цитата (Эрфеа) »

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

Предрассудки. Делал тонну раз, всё ок. А ещё я смотрю, у вас тонна лишних денег и свободного времени.

Цитата (Эрфеа) »

А на фига простите эту помойку на дисковой подсистеме держать?! tmpfs и в лёгкий (или точнее нереально шустрый) путь, я уже говорил про оперативу

Аха, только если tmpfs занят, то оперативная память занята мусором и всё становится очень плохо. Я у себя на ноуте использую tmpfs, но это из-за того что у меня SSD-диски. Тут уже от потребностей, кому что надо... Но я не вижу никаких оснований использовать ext3 для "/tmp".

Цитата (Эрфеа) »

А меня нет, чтяднт?

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

[Эрфеа]

Цитата (Xaionaro) »

Предрассудки. Делал тонну раз, всё ок.

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

Цитата (Xaionaro) »

Аха, только если tmpfs занят, то оперативная память занята мусором и всё становится очень плохо. Я у себя на ноуте использую tmpfs, но это из-за того что у меня SSD-диски. Тут уже от потребностей, кому что надо... Но я не вижу никаких оснований использовать ext3 для "/tmp".

Размер tmpfs можно ограничить, а уж подчищать /tmp не проблема (автоматизоровать такую тупую операцию должен уметь каждый сисадмин) да и засерается то она не ахти как между прочим). Всяко лучше чем срать на дисковую подсистему, она всегда была узким местом по скорости операций.

Добавлено через 1 минуту

Цитата (Xaionaro) »

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

Может лучше железо подстраивать под задачи, а не наоборот?! Не пробовали?

[Xaionaro]

Цитата (Эрфеа) »

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

XFS существует уже очень давно, механизм наращивания уже отработан до нельзя.. Тем более сам механизм, как мне кажется, до жути примитивен.

Цитата (Эрфеа) »

Размер tmpfs можно ограничить, а уж подчищать /tmp не проблема (автоматизоровать такую тупую операцию должен уметь каждый сисадмин) да и засерается то она не ахти как между прочим). Всяко лучше чем срать на дисковую подсистему, она всегда была узким местом по скорости операций.

И ещё, в некоторых случаях в /tmp требуется больше 5GiB на какую-нибудь операцию (например компиляция какой-нибудь фигни типа OOo, ну или в меньших масштабах, но тоже пример, установка какой-нибудь большой и кривой софтины, которая сначала распаковывается в /tmp), что невсегда приятно с tmpfs. ... особенно на машине, где всего 1GiB ОЗУ.

Цитата (Эрфеа) »

Может лучше железо подстраивать под задачи, а не наоборот?! Не пробовали?

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

[Эрфеа]

Цитата (Xaionaro) »

XFS существует уже очень давно, механизм наращивания уже отработан до нельзя.. Тем более сам механизм, как мне кажется, до жути примитивен.

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

Цитата (Xaionaro) »

И ещё, в некоторых случаях в /tmp требуется больше 5GiB на какую-нибудь операцию (например компиляция какой-нибудь фигни типа OOo, ну или в меньших масштабах, но тоже пример, установка какой-нибудь большой и кривой софтины, которая сначала распаковывается в /tmp), что невсегда приятно с tmpfs. ... особенно на машине, где всего 1GiB ОЗУ.

При компиляции ООо не отжирается 5GiB на /tmp впринципе как таковых (и даже рядом цифр нету), если вы не в ней собираете естественно. Интересно что же вы такого ставили что в unix отожравшего так невообразимо много места на /tmp?! Да и опять же что мешает раз имеется такая бяка, просто взять и remount перед и после операции, хотя мне кажется в самом дерьмовом случае, полезет в своп и всё пройдёт успешно.

Цитата (Xaionaro) »

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

Ну вот смотрите появляется задача, что вы делаете, лезете в помойку за железом?! Я заказываю и сразу под нужные задачи, тут есть место и о запасе подумать, но пять 5% производительности разницы в ПО значения играть не будут.
У нас видимо разные подходы к работе, я работателю при появлении какой либо задачи, отчитываюсь как есть сколько это будет стоить в закупках, еже он начинает выкручиваться вот дорого или что в ту сторону, предлагаю по возможности на старом железе с ОГРОМНОЙ оговоркой что потом не жаловаться что что-то медленно или так далее. Ну сам посуди ну оптимизируешь ты барахло, ну +10% производительность тебе кто-то скажет спасибо, кто вообще заметит?! А вот не дай бог что-то не так пойдёт в узко месте, виноват ты. Ну и нафига оно так, я обеспечиваю безперебойную работу и экономлю деньги работодателя не на мифических плюсах от супер ПО а на надежности и стабильности принятых мной решений, на обеспечении отказоустойчивости и исключении простоев. Припомнился терминальник на виндавс сервере с одной фирмы, ввиду особеностей данной супер ОС, местным одминам приходилось его (изредко) ребутать посреди дня, простой был 30 минут, я такого не допускаю.

[Xaionaro]

Цитата (Эрфеа) »

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

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

Цитата (Эрфеа) »

При компиляции ООо не отжирается 5GiB на /tmp впринципе как таковых (и даже рядом цифр нету), если вы не в ней собираете естественно. Интересно что же вы такого ставили что в unix отожравшего так невообразимо много места на /tmp?! Да и опять же что мешает раз имеется такая бяка, просто взять и remount перед и после операции, хотя мне кажется в самом дерьмовом случае, полезет в своп и всё пройдёт успешно.

Я нередко видел системы, где OBJDIR направлен в /tmp/obj. И не считаю это глупым... разве что достаточно специфично. Тем более это не отменяет того, что существуют большие программы с закрытым кодом, которые при установке распаковывают себя в "/tmp".
BTW,

To build OOo, you should have a lot
of free diskspace (~ 11GB) and memory (~ 2GB).

По поводу remount, не все процессы потерпят, если вдруг потеряют доступ к файлам, с которыми они работают. И не так то мало процессов не работают с временными файлами в "/tmp", другими словами, как раз вот этот путь - это искусственные грабли.

Цитата (Эрфеа) »

Ну вот смотрите появляется задача, что вы делаете, лезете в помойку за железом?! Я заказываю и сразу под нужные задачи, тут есть место и о запасе подумать, но пять 5% производительности разницы в ПО значения играть не будут.

Во-первых, у меня есть маленькая почти собственная локалка, где все делалось из своего кармана, и там это просто нереально закупать всё с расчётом на RAID и прочие радости. Во-вторых, даже в случай серьёзной конторы, начальство может тупо отказать в покупке железа на какие-то нужды. По поводу производительности лишь например http://www.phoronix.com/scan.php?pag...nchmarks&num=2 .. Хотя пофиг что в статьях пишут, я для себя знаю, производительность иногда отличается достаточно сильно. И для разных нужд надо выбирать разные ФС и сколько раз не повторяй ты свои "5%" ты не переспоришь мне известные факты. Как я уже говорил, это спор не о чём.

Цитата (Эрфеа) »

У нас видимо разные подходы к работе, я работателю при появлении какой либо задачи, отчитываюсь как есть сколько это будет стоить в закупках, еже он начинает выкручиваться вот дорого или что в ту сторону, предлагаю по возможности на старом железе с ОГРОМНОЙ оговоркой что потом не жаловаться что что-то медленно или так далее. Ну сам посуди ну оптимизируешь ты барахло, ну +10% производительность тебе кто-то скажет спасибо, кто вообще заметит?! А вот не дай бог что-то не так пойдёт в узко месте, виноват ты. Ну и нафига оно так, я обеспечиваю безперебойную работу и экономлю деньги работодателя не на мифических плюсах от супер ПО а на надежности и стабильности принятых мной решений, на обеспечении отказоустойчивости и исключении простоев. Припомнился терминальник на виндавс сервере с одной фирмы, ввиду особеностей данной супер ОС, местным одминам приходилось его (изредко) ребутать посреди дня, простой был 30 минут, я такого не допускаю.

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

И хватит! Хватит уже спорить о религии. У вас есть необоснованные предрассудки (я уже понял, что вы программист и можете представить как именно это работает, но и я тоже программист, давайте не будем продолжать), что наращивать опасно; я тонну раз наращивал, и моё начальство в одной конторе, тоже тонну раз наращивало ещё за несколько лет до меня... и всё ОК... У вас так же есть убеждение, что производительность не отличается. А у меня обратные убеждения, и сколько бы мы не говорили, мы друг друга не переубедим. Я очень прошу, попытайтесь писать пост по этому холивару так, чтобы не требовался мой ответ.