Holy War (Linux vs FreeBSD)

lexa - 17/Июл/2011 19:38

Вынесу из каментов к прошлому посту:

номер раз:

Это значит что с дисковой/fs в линуксе все настолько загадочно и хреново, что у нас ротейт логов на одной из машин роняет ее регулярно раз в месяц (логи то ротейтятся мгновенно, только апач больше не работает) и помогает только reboot -fn. А на десктопе при копировании больших файлов все задумывается так что анекдот про "сейчас дискетка отформатируется..." как раз про современные Линуксовые ядра. Debian/2.6.разные, ext3/4.

номер два:

Я ловил клина на полминуты только при удалении больших пачек больщих файлов (ie по полгига где-то)

Типа записал жене сериал/дитю мультиков на болванку -- хочешь грохнуть исошку/исходники -- и оно тупит минуты две. В 2.6.39 xfs порефакторили сильно (осталась только его "родовая" болезнь -- файл при создании и до закрытия (или до fsync?) имеет только dnode, и если начать копировать файл (ту же исошку) и в середине дернуть питание -- файл будет пустой)

С другой стороны у меня 4 машины с XFS везде кроме /boot и убитого XFS я не видел еще (хотя питание у меня тут весьма нестабильное)

И, рискуя (стремясь!) спровоцировать Holy War, спрошу я вас: че, типа, так и есть?. И считается нормальным? Ну ладно, xfs вроде починили, но ведь было?

Update: в каментах сообщили правильное название, "баг 12309". Поиск в Яндексе "Linux 12309" приносит истинные лулзы!

Справедливости ради два пункта:

  1. При неблагоприятном положении светил, как то одновременный бэкап (с записью сотни гигов на медленный раздел), uTorrent (на том же разделе), антивирус проснулся и захотел мои терабайты проверить, виртуальная машина сожрала всю память я иногда вижу такое на Win7. Но это, натурально, событие. Ну раз в месяц такое бывает, или даже реже. Симптомы - именно что почти полная блокировка, программу новую не запустить. И грешу я тут больше на драйвер SAS, потому что после переноса всего рабочего на SSD на SATA (на SAS-raid остался только онлайн-архив и прочие бэкапы) - вроде не повторялось.
  2. Опять же на FreeBSD, когда ей (/от нее) по сети что-то быстро льется (100-120Mb/sec у меня) в один поток, если завести, к примеру, второй большой поток - будет тормозить. Всякие df естественно тормозят и так далее. Но это не замирания на полминуты, это именно heavy IO на медленных дисках, симптомы всем хорошо известны: очередь длинная, дерганая, среднее svc_t большое. И за последние года два я не помню замираний на исправном железе, только если вдруг SATA timeout, тогда да.

Comments

_slw (not verified) - 17/Июл/2011 19:47

не, ты что, правда думал, что хорошо там, где нас нет?

lexa - 17/Июл/2011 19:57

Ну как-то ТАКОЙ пакости я не ожидал.

У меня Linux используется очень мало, он меня раздражает (потому что все в нестандартных непривычных местах), но зато WS для CUDA просто "берет и работает", все взяло и поставилось.

А вот что там в IO водятся драконы - и в голову не приходило.

avnik (not verified) - 17/Июл/2011 20:01

дебиан по моему чемпион по стандартизации всего и вся (по крайней у всего есть логика, хотя и извращенная)

lexa - 17/Июл/2011 20:04

У меня то привычки FreeBSD-шные в любом случае.

А Debian меня пугает разными способами, пока живу на OpenSUSE.

avnik (not verified) - 17/Июл/2011 20:08

Это какими же? ;)

PS Впрочем у меня всегда с фрей плохо складывалось, с нетбсд как-то было понятнее...

lexa - 17/Июл/2011 20:10

Ну, например, мне иногда пишут maintainer-ы пакета LibRaw на Debian (как автору) и хотят чего-то очень странного.....

Давно, кстати, не писали, надо проверить какая там у них версия в репозитории...

avnik (not verified) - 17/Июл/2011 20:17

Подозреваю -- что хотят они --enable-shared ;)

0.13.1-2 в unstable

lexa - 17/Июл/2011 20:35

Так уже есть, начиная с 0.13.2, это какой-то еще Linux захотел, хотя в случае с LibRaw это должно создавать больше проблем, чем решать.

Не, там хотели чего-то абсолютно странного и давно, не в этом году.

dil (not verified) - 17/Июл/2011 21:57

В squeeze (stable) - 0.9.1-1, в wheezey (testing) и sid (unstable) - 0.13.1-2

lexa - 17/Июл/2011 22:10

Ну че, молодцы, что тут скажешь.

0.13.1 - свежая, 8 февраля сего года. Текущая в stable-ветке 0.13.7

_slw (not verified) - 17/Июл/2011 22:43

и так у них всё...
http://kranov.livejournal.com/25660.html

lexa - 17/Июл/2011 22:44

Интереснее что там с 4k blocksize

_slw (not verified) - 17/Июл/2011 22:55

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

poige (not verified) - 21/Июл/2011 16:00

Там, где вас нет, реально хорошо, поскольку любой фанатизм это уже как правило диагнозъ.

shaman007 (not verified) - 17/Июл/2011 19:58

По крайней мере в домашних условиях УМВР.

avnik (not verified) - 17/Июл/2011 19:59

Ну клина я ловил именно "при положении светил", то есть удаление с xfs монтированой через nfs, кеша задроченого долгим чтением (mv -f /mnt/nfs/... .), активно читающего/пишущего rtorrent и файрфоксе в состоянии "ща будет oomkill"), и ядро на том хосте какое-то непонятное .34

PS и если локалхост "нормальная, хоть и сильно не новая машина", то там что-то собраное на коленке из подручных говен.

Anonymous (not verified) - 17/Июл/2011 21:11

сдается мне, что замирания -- это bug 12309: http://bugzilla.kernel.org/show_bug.cgi?id=12309

_slw (not verified) - 17/Июл/2011 21:14

куда-то камент сожрался.

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

lexa - 17/Июл/2011 21:26

Небось BSD-шный маллок спасет :)

avnik (not verified) - 17/Июл/2011 22:40

Там косяк в аллокаторе джаваскрипта, архитектурный.
Я недавно видел блогпост одного из разработчиков -- http://blog.mozilla.com/nnethercote/2011/07/06/memshrink-progress-week-3/ на тему что там течет, и почему. кратко -- оно не может освободить arena пока там жив последний джаваскриптовый объект, и если я правильно понял телегу про segregation они там добавили stop-n-copy для "долгоживущих" объектов JS.

_slw (not verified) - 17/Июл/2011 22:56

ну и чего бы им на каждый таб не иметь свою арена?

avnik (not verified) - 17/Июл/2011 23:03

Так у UI/экстеншном свои "общие" арены (они фиксированого размера -- как и у любого аллокатора на "много мелких объектов одинакового размера")

_slw (not verified) - 17/Июл/2011 23:14

ну.
у UI -- свой
у каждого экстненшена -- свой
у каждого таба для его жабоскриптов -- свой.
таб закрыли -- арену грохнули

avnik (not verified) - 17/Июл/2011 23:24

Ага, а арены с DOM -- общие.
Точнее может даже и свои, но пока на объект там ссылается кто нибудь из UI или какого нибудь greasemonkey он не освободится.

_slw (not verified) - 17/Июл/2011 23:27

кто может ссылаться на объект в грохнутом табе?

avnik (not verified) - 17/Июл/2011 23:36

В грохнутом - нет, а вот GC может не дать его грохнуть, пока что нибудь из потрохов туда указывает
(мозилла же почти вся на JS написана сейчас -- так что там везде JS && GC)

_slw (not verified) - 17/Июл/2011 23:44

так надо форсить!
а то задрали подвисшие и зациклившиеся на оборваном соединении скрипты

avnik (not verified) - 17/Июл/2011 23:50

Надо, хотя это и другая проблема

poige (not verified) - 21/Июл/2011 16:03

BSD'шный malloc, aka jemalloc, был засунут в Firefox 3 какой-то, именно в надежде на то, что оно поможет. Если и помогло, то отнюдь не так круто, как на то рассчитывали, и сейчас, как пишут в новостях, мозильские разрабы в рамках какой-то раб. группы обсуждают как бы им написать Google Chromeпобороть mem. frag.

iskatel (not verified) - 18/Июл/2011 00:33

не жутко, но течёт. Как и в Винде, в общем-то.

dil (not verified) - 17/Июл/2011 21:47

Не знаю, у меня уже не первый год всё работает. Дома 3.6.18, на работе уже 5-с-чем-то, и ни разу никаких проблем с утечкой памяти не наблюдал.

_slw (not verified) - 18/Июл/2011 00:38

у меня по месяцу висит в примерно константныъ объемах.
на больше обычно лектричества не хватает

iskatel (not verified) - 18/Июл/2011 00:40

Так у меня и в линуксе Опера с Фоксом висели подолгу, при том, что окошек открывалось много.

dil (not verified) - 17/Июл/2011 21:53

Про XFS никогда не пробовал, не скажу.

А насчет ротации логов - это ж просто переименование старых логов и посылка сигнала апачу, чтоб он их открыл заново. (собственно, кому я рассказываю :)
Обе операции не ресурсоёмкие, я не понимаю, где там в принципе можно накосячить.
Ресурсоёмкость начинается дальше, когда логи сжимаются и удаляются. Там могут быть проблемы с производительностью, но чтоб настолько фатальные...

deadmustdie (not verified) - 17/Июл/2011 22:24

XFS - замечательная файловая система для серверов, защищенных UPS и имеющих автоматику гашения на случай исчерпания батареи. Linux+XFS без UPS = потеря данных (рано или поздно).

Ходят упорные слухи, что на системные платы серверов SGI, для которых разрабатывалась XFS, в обязательном порядке снабжались батареями. И пропадание питания вызывало на уровне ОС прерывание, по которому содержимое "незакоммиченного" кеша сбрасывалось на энергонезависимую память. Естественно, в Linux/x86 такой поддержки нету.

lexa - 17/Июл/2011 22:40

Там же, типа, журнал?
Т.е. текущая транзакция имеет право пропасть, но все покоммиченные - потом накатятся?

deadmustdie (not verified) - 18/Июл/2011 09:24

Тут все дело в том, что данные (насколько я это понимаю) в журнал не пишутся, а пишутся в кэш. Который по умолчанию сбрасывается на диск после закрытия файла и/или после fsync(). Естественно, при O_DIRECT кеш не задействован, но и скорость соответствующая.

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

Файловые системы - это всё-таки не реляционные СУБД, режим постоянной записи всех данных в журнал им в большинстве случаев противопоказан.

lexa - 18/Июл/2011 10:35

Ну это вроде бы нормальное поведение - пока fsync() не сделан нельзя быть уверенным, что (все) записалось.

Или XFS и на fsync тоже кладет с прибором?

deadmustdie (not verified) - 18/Июл/2011 10:46

На fsync()-то конечно не кладет, просто есть немаленькое количество софта (в том числе, как я слыхал, примерно половина KDE), для которого характерна перезапись конфигурационных файлов в процессе работы. Получаются типовые грабли при пропадании питания - какая-нибудь гуевая штуковина перестает запускаться, злобно ругаясь на очередной конфигурационный файл.

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

Гр-н Торвальдс даже как-то прокомментировал все это в том смысле, что нечего на ядро пенять, коли пользовательский софт кривой. Его тогда, правда, многие стали забрасывать гнилыми помидорами.

lexa - 18/Июл/2011 11:09

Ну как сказать
- если при пропадании питания (перезаписанный) файл остался как был - это нормально.
- если он был длинный (больше блока FS) и перезаписался куском - это плохо, но неудивительно.

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

avnik (not verified) - 17/Июл/2011 23:28

Слухи.
По крайней мере в low end SGI я такого не видел.

И я еще раз повторюсь, в условиях нестабильного питания я "убитого" насмерть XFS я не видел ни разу

proforg (not verified) - 18/Июл/2011 00:01

тут кому как повезёт :)
у меня как то XFS убилась так (на сервере, в дц, пара хаявок на ребут кнопкой reset), что ядро при её виде (попытке подмонтировать / отрепейрить) падало в panic
reiserfs 3й, про который пишут что он сам по себе даже сыпется, при это, ни разу никаких нареканий не вызывал.

deadmustdie (not verified) - 18/Июл/2011 09:26

Дык дело не в убиении всей ФС, а в порче последних перезаписываемых/создаваемых файлов.
Полную смерть XFS-тома я ещё ни разу не видел, даже после повреждения на физическом уровне обычно удается слить остатки через dd и, починив, смонтировать.

kika (not verified) - 19/Июл/2011 03:52

Я видел. Сделав XFS на 16Т. Результат оказался невосстановим (но воспроизводим).

rezdm (not verified) - 17/Июл/2011 22:28

Я как-то на солярке пробовал понасоздавать всякого: http://rezdm.livejournal.com/171053.html
Живёт

lexa - 17/Июл/2011 22:39

Я с тех пор (переведя все в 1251) живу совершенно без проблем. ZFS поапгрейдилась раза три (была тогда что-то вроде v13, сейчас 28), может быть сейчас проблема и вовсе ушла.

Что не отменяет того факта, впрочем, что для русских имен в utf8 ограничение длины было 127 символов, а не обещаные 255.

rezdm (not verified) - 17/Июл/2011 22:41

Я больше про клины ФС. Можно попробовать ту мульку запустить на екст3, иксэфэс и уфс2, посмотреть, как оно будет выживать. Помнится, на линухе (вот каком и с какой фс, сейчас не припомню) я словил дикого "оп, всё остановилось".

lexa - 17/Июл/2011 22:46

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

rezdm (not verified) - 17/Июл/2011 22:47

Доверия всё равно больше.

vasiliy (not verified) - 17/Июл/2011 23:58

Мой дебиан при удалении 50Гб файла через SMB c ext4 входит в клинч на 8 секунд, даже по сети не подсоединиться по VNC в этот момент. EXT4 на системном разделе у меня разок ложился напрочь при внезапном ребуте, приходилось из бэкапа разворачиваться.

Наверное выдам крамольную мысль, но из вариантов ext3, ext4 и xfs мне больше всего понравилось поведение ....NTFS, правда с kernel-mode драйвером от Paragon (единственный минус - фришная версия на сайте не умеет дефрагментировать и проверять на ошибки). Зато на ошибки можно проверить тулзой из комплекта NTFS-3G (тормоз тот еще). Процессор грузит меньше, шуршит быстро, советую попробовать.

И в любом случае, без UPS нужно быть очень осторожным в выборе, так как линуксовые ФС либо настроены на надежность, либо на скорость (но нужно выбрать что-нибудь одно из списка, а потом соответствующую ФС: большие файлы, мелкие файлы, много потоков и т.п.).

iskatel (not verified) - 18/Июл/2011 00:31

Я не знаю, чем били по рукам тех криворуких людей..

> у нас ротейт логов на одной из машин роняет ее регулярно раз в месяц (логи то ротейтятся мгновенно, только апач больше не работает) и помогает только reboot -fn

Налицо проблема с машиной. Причем тут ФС, где таких проблем нет в принципе уже много лет ?

>> на десктопе при копировании больших файлов все задумывается так что анекдот про "сейчас дискетка отформатируется..." как раз про современные Линуксовые ядра. Debian/2.6.разные, ext3/4

Проблема, в общем, есть, только она снова не имеет никакого отношения к ФС.
Планировщики IO чаще всего оптимизированы под серверную нагрузку.

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

Кто виноват людям, сидящим в 2011-м году на 1 гиге памяти и большом свопе ?

И вот сочетание всего этого с медленными дисками иногда даёт именно то самое "сейчас дискетка отформатируется..."

>> хочешь грохнуть исошку/исходники -- и оно тупит минуты две.

Если речь про винт 2004-го года - верю. Если речь про некие самособранные криворуким гентушником/слакварщиком ядра - тоже верю.

А так... просто sata диск, ext3/4, чпок- удалили iso-шки, проблем-то.

_slw (not verified) - 18/Июл/2011 00:40

Проблема, в общем, есть, только она снова не имеет никакого отношения к ФС.
Планировщики IO чаще всего оптимизированы под серверную нагрузку.
как это относится к rm из шела?

iskatel (not verified) - 18/Июл/2011 00:43

Читай внимательно.
Разжевываю:

Указано, что "Проблема, в общем, есть, только она снова не имеет никакого отношения к ФС."

Далее перечислены 3 причины,
1) Планировщики IO чаще всего оптимизированы под серверную нагрузку.
2) К этому добавим своп
3) сочетание всего этого с медленными дисками ...

которые в сумме
иногда дают именно то самое "сейчас дискетка отформатируется..."

_slw (not verified) - 18/Июл/2011 00:47

очень хорошо.
rm на сервере не бывает или что?
rm на сервере сверхприоритетная операция или что?
какое отношение своп к rm?

ну да, с быстрым диском будет быстрее, ваш к.о, но остальное-то причем?

iskatel (not verified) - 18/Июл/2011 00:48

не вижу никаких проблем с rm. В тч. с rm на пачку iso-шек.
ext3/4 .

_slw (not verified) - 18/Июл/2011 00:50

исошки недостаточно большие?
возьми бюрэйную исошку

iskatel (not verified) - 18/Июл/2011 00:54

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

Раньше на предыдущих ядрах и медленных дисках было дольше, сейчас быстрее, потмоу как за последние 6 лет значительно лучше стали и ext*, и сами диски, и планировщики в ядрах.

Да, я тут говорю только про стабильные ядра от RHEL, и немного про ядра OpenSUSE, а вот как работает ядро, что собрал Вася-на-всю-голову-гентушник - один /dev/null ведает.

_slw (not verified) - 18/Июл/2011 00:56

ну rhel.
пусть
будет замирание всего.

iskatel (not verified) - 18/Июл/2011 01:24

iso-шка dvd:

$ sudo time rm test1
0.00
user 0.61
system 0:00.61
elapsed 99%CPU (0avgtext+0avgdata 2352maxresident)k
0inputs+0outputs (0major+175minor)pagefaults 0swaps

и не успеть что-то там открыть.
(sudo для получения более подробн. стат-ки)

сделал 10G файл :

100+0 records in
100+0 records out
10485760000 bytes (10 GB) copied, 114.578 s, 91.5 MB/s

удалим :

$ time rm file

real 0m1.438s
user 0m0.000s
sys 0m1.423s

какие к черту замирания ?

сделал 20G файл :

$ 200+0 records in
200+0 records out
20971520000 bytes (21 GB) copied, 296.888 s, 70.6 MB/s

$ sudo time rm file
0.00user 0.00system 0:00.01elapsed 15%CPU
(0avgtext+0avgdata 2352maxresident)k
112inputs+0outputs (1major+174minor)pagefaults 0swaps

это все на паре медленных (cравнивая с лучшими sata-шками) sata Barracuda 7200.11, на кот. raid1->lvm->ext4.

Причем параллельно есть некоторая нагрузка по IO, пусть и небольшая.
(видно на скорости вбрасывания байтиков в 20G файл)
на sata-шках поновее будет ещё быстрее.

lexa - 18/Июл/2011 01:05

Не-не, я тут чую противоречие.

Если "оптимизированы под серверную нагрузку", то очевидно что "собственно rm" делаем где-то в фоне, блокировки всех прочих процессов недопустимы (потому что там где-то спит самый главный серверный процесс).

Т.е. блокировка в целях "быстро быстро освободить место" - это не серверная, это десктопная оптимизация.

settler (not verified) - 18/Июл/2011 01:00

Теперь уже диски медленные. Не знаю о чем вы подумали, но у меня там 2 * Intel SSD по 160гигабайт. И памяти 12 гигабайт. и два 4 ядерных проца. Херово оно работает с новым железом, вот и все. А Линукс туда мы зафигачили только потому, что с этими SSD линейная скорость записи была 250мб/c, против 100мб/c (ровно) на FreeBSD 8.1. Очень может быть что скоро снесем и будет там как везде фряха.

iskatel (not verified) - 18/Июл/2011 01:08

так нет проблем с rm, в том-то и дело.

lexa - 18/Июл/2011 09:15

Тьфу, не ту ссылку дал, а редактировния нет.

Мне тут нагадили в blog.lexa.ru в комменты правильными ссылками:
https://bugzilla.kernel.org/show_bug.cgi?id=12309 (500+ комментариев)
http://lurkmore.ru/12309

Ну и вообще народ жалуется. Поиск "Linux 12309" в Яндексе доставляет реально.

Из чего я делаю вывод, что бага есть, но проявляется только при Юпитере в созвездии Рыб.

iskatel (not verified) - 18/Июл/2011 14:16

а теперь, пожалуйста, прочитай по приведенным тобой же ссылкам сам текст.

в нормальных ядрах такой проблемы, как правило, НЕТ. Как минимум в острой форме.
"2.6.18 сбою не подвержен, а команда разработчиков энтерпрайсного RHEL бэкпортирует в него некоторые фичи и драйверы из новых версий ядер"

Дело не в Юпитере.
Просто используй качественные, энтерпрайзные ядра.

-------------
скорость удаления файлов по 10-20 гиг на ext4 - мгновенно.
С нормальным ядром и на ext3 теперь тоже быстро, патчи добавлены пару лет тому.
-------------

"Существует, однако, 100% способ избавиться от этой полезной фичи под номером 12309. Состоит он в том, что надо:

Выкинуть все свистоперделки из системы,
Поставить 100 Hz таймер ядра и No Forced Preemption (Server) mode,
Оставить обычный системный планировщик i/o,
Врубить всему юзерспейсу приоритет ionice пониже (2, лучше 3), а ядру повыше (1 real time),
Никаких экспериментальных reiser4.
При копировании не врубать высокий приоритет этому приложению или выкинуть этот грёбаный дистрибутив, где по дефолту этому ставится высокий priority.
Желательно откатиться на старое ядро нескольколетней давности. Например 2.6.18 сбою не подвержен, а команда разработчиков энтерпрайсного RHEL бэкпортирует в него некоторые фичи и драйверы из новых версий ядер. "

lexa - 18/Июл/2011 14:34

Я не понимаю вот такой простой вещи: а отчего все это не сделано вообще во всех дистрибутивах?

Ну то есть я достаточно легко добился замерзания всего нахрен, просто поставив Suse 11.4 по дефолту, никаких "свистоперделок" не ставил. Да, пришлось дать много IO, да, оно не гарантированно получается, но
а) проблема есть
б) ну так, по секрету, я вообще не в курсе, как сделать описанное выше (таймер ядра и так далее), линуксом 15 лет не пользуюсь. Дайте, типа, менюшку
в) 2.6.18 - это, как я нашел, 2006-й год. Чипсеты, SSD TRIM, SATA-600?

iskatel (not verified) - 18/Июл/2011 14:43

ты что ж это такое говоришь , еретик ? 8~)

В свободном красноглазом GNU мире каждый извращается так, как он хочет 8=-)
Вот и имеем то ли 50, то ли 100 дистрибутивов, и большинство пригодны исключительно для отправки в /dev/null.

>> просто поставив Suse 11.4 по дефолту

неплохая десктопная система, да. Но этта, не серверная. И с IO не очень.
А теперь вставь туда свежее ядро от SLES11 (кажется, свежак там основан на 2.6.32 + тонна патчей).
Будет полегче, но без всяких там свежих драйверо-поддержек для десктопного железа.
------------

>> не в курсе, как сделать описанное выше (таймер ядра и так далее), линуксом 15 лет не пользуюсь. Дайте, типа, менюшку

Эхх. Увы. конфиги-с.

>> 2.6.18 - это, как я нашел, 2006-й год. Чипсеты, SSD TRIM, SATA-600?

в RHEL5 - да по интелёвым (и не только) чипсетам, не в курсе по ssd, да по sata (не по всем чипсетам).
Это ж по сути не 2.6.18, это энтерпрайзное ядро, основанное на 2.6.18 + примерно 3-5 тыс. патчей.

да, уже скоро год, как вышла RHEL6, с таким же энтерпрайзным ядром, но основанным на 2.6.32, и тоже примерно + 5 тыс. патчей.

Есть тормоза при IO загрузке (и большие - если у нас sata), но не тотальное замирание всего.

Ещё есть энтерпрайзное ядро, основанное на 2.6.32, от Оракла - это если кому нужна OCFS2. Пока не работал с ним.

lexa - 18/Июл/2011 14:57

Так как я не хочу в "свободный красноглазый", а хочу честный монолитный FreeBSD, только с CUDA, OpenCL, возможно - с виртуализацией гипервизором, то просто спрошу рекомендации дистрибутива.
Хочется
а) пресловутого стабильного ядра
б) но свежий девелоперский userland (gcc 4.5 или 4.6, соответствующие libstdc++, свежий Xemacs и так далее)
Не хочется собирать всего из исходников, жизнь коротка, хочется брать из вменяемого репозитория.

SuSE по пункту б) меня вполне удовлетворяет. По пункту а) - получается что нет.

iskatel (not verified) - 18/Июл/2011 15:26

RHEl6 в виде клона по имени SL6
http://ftp1.scientificlinux.org/linux/scientific/6.0/x86_64/

C gcc есть некоторое отставание, системный есть и будет
$ gcc -v
gcc version 4.4.4 20100726 (Red Hat 4.4.4-13) (GCC)

но обычно свежие потом включаются в дистр в виде technology preview пакетов.
те. 4.5-4.6 будут, но не факт, что сейчас

kika (not verified) - 19/Июл/2011 03:57

RHEL6? там правда гцц 4.4.5

settler (not verified) - 18/Июл/2011 00:50

>Налицо проблема с машиной. Причем тут ФС, где таких проблем нет в принципе уже много лет ?

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

> Кто виноват людям, сидящим в 2011-м году на 1 гиге памяти и большом свопе ?
памяти 8 гигабайт, x86_64. Откуда фантазии про 1гиг? :)

не продолжайте, не интересно.

settler (not verified) - 18/Июл/2011 00:45

это оно http://lurkmore.ru/12309 :)
ну или серьезно https://bugzilla.kernel.org/show_bug.cgi?id=12309

mrshurik (not verified) - 18/Июл/2011 00:46

тормоза при доступе к диску под Линукс - так и есть. 5 лет использую Линукс на десктопе на работе, страшно напрягает это.

Anonymous (not verified) - 18/Июл/2011 14:11

У меня Linux на дескторпе с 1997г, о каких тормозах вообще речь?

lexa - 18/Июл/2011 14:38

В 95-м году я вынес нахрен Linux из всей области вокруг себя, перешел на FreeBSD 2.1, УЖЕ ТОГДА безобразно тормозило :)

Anonymous (not verified) - 19/Июл/2011 01:40

"УЖЕ ТОГДА" у FBSD была одна клёвая фишка, по сравнению с линуксом: при нехватке RAM в своп выкидывались процессы "кластерами", давая возможность оставшимся хоть как-то работать, затем "кластера" менялись. А без нехватки RAM особой разницы то и не было. Точнее, я не наблюдал. СКОтский оракл под линуксом заводился, а под FBSD нет, это определило мой выбор в тот момент. Так же, как сейчас твой выбор определяется CUDA&Co.

_slw (not verified) - 01/Авг/2011 22:00

я тут кстати пролистал листы за последние три года.

Date: Thu, 30 Jun 2011 19:23:15 +0300
From: Kostik Belousov

[Please remove current@ when replying.]

I created the first code drop for the ongoing GEM/KMS project. Please
note that this is not an end-user release, and even _not_ a call for
testing. The project is not finished yet, and I expect quite more
efforts from me even after the scheduled project end, and from ports/x11
people, before the driver and usermode infrastructure will be ready for
the general public consumption.

That said, the patch is only of use for you now if you want to review,
debug or otherwise help the project. The driver is known to be unstable,
some parts are missing, some (esp. VM changes) are under the discussion
and propably will be changed.

If you have fix or useful bug analisys or suggestions for improvements,
you are welcome. I will not answer to the support requests for this
code now, please do not waste your time asking for it.

The pointers to the patches, useful hints for debugging and bug
reporting, and some notes are at the http://wiki.freebsd.org/Intel_GPU.
I will maintain this page further.

Current patch is ~50KLOC, it took quite an efforts to bring the code to
the state where there is something to debug. Thanks for everybody who
waited for it, and please be patient while the further work is done.