[Comm] ядро 2.6.30 и xfs

[Comm] ядро 2.6.30 и xfs

[Денис Назаров]

Сделал таки второй подход и поставил на свой ноут бету 5.0, 
обновил до 5.1 и начал "наслаждаться" странностями - включение
проходило примерно так - все грузится, как только стартуют 
иксы - получаю мертвый вис. После принудительного выключения
запуск проходит нормально. Выключение проходило примерно
так же - как только иксы выгружались, опять получал вис,
винт иногда что-то там подергивал, приходилось принудительно
выключать, удерживая кнопку питания. Происходило все это через
раз (примерно), но, когда после очередного такого затыка kmail
предложил настроить учетку, мне это дело надоело. Пытался 
после затыка с загрузкой грузиться с livecd и копаться в логах -
никакого криминала не обнаружил. Подозрение пало на ФС - три 
раздела на винте - /usr, /, /home - и все в xfs. На 4.1 с ядром
2.6.25 проблем не было никаких больше года, подумал, что виновато
ядро 2.6.30. Переформатировал все в ext3, переставил систему и вот
уже три дня полет нормальный. Кто нибудь может подтвердить баги
ядра 2.6.30 в отношении XFS?

Re: [Comm] ядро 2.6.30 и xfs

[Gleb Kulikov]

В сообщении от [Четверг 26 ноября 2009 Денис Назаров] написал:

> раздела на винте - /usr, /, /home - и все в xfs. На 4.1 с ядром
> 2.6.25 проблем не было никаких больше года, подумал, что виновато
> уже три дня полет нормальный. Кто нибудь может подтвердить баги
> ядра 2.6.30 в отношении XFS?

У меня традиционно XFS, всего больше 2 десятков машин. Проблем замечено не 
было (кроме описанных с kde при жёсткой перезагрузке, очень уж агрессивно кде 
переписывает вои файлы конфигурации).

PS: мне понравилось держать важное из ~/.kde* в git :)

-- 
      Салют, /GLeb

UIN: 15341920
jabber://gleb@asd.iao.ru
sip://2387245@sipnet.ru			(telephony)
skype://gleb_kulikov.tomsk		(telephony)
sip://20000204@sip.pctel.ru		(telephony)

Re: [Comm] ядро 2.6.30 и xfs

[Michael Shigorin]

On Thu, Nov 26, 2009 at 04:11:23PM +0600, Gleb Kulikov wrote:
> > Кто нибудь может подтвердить баги ядра 2.6.30 в отношении
> > XFS?
> У меня традиционно XFS, всего больше 2 десятков машин. Проблем
> замечено не было (кроме описанных с kde при жёсткой
> перезагрузке, очень уж агрессивно кде переписывает вои файлы
> конфигурации).

УМВР, но для ноутов XFS не могу рекомендовать -- kernel thread'ы
генерируют дополнительные wakeup'ы.  Если вылизывать машинку,
то придётся возвращаться на ext3+relatime/noatime.

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

Re: [Comm] ядро 2.6.30 и xfs

[Gleb Kulikov]

В сообщении от [Четверг 03 декабря 2009 Michael Shigorin] написал:

> 
> УМВР, но для ноутов XFS не могу рекомендовать -- kernel thread'ы
> генерируют дополнительные wakeup'ы.  

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

> Если вылизывать машинку,
> то придётся возвращаться на ext3+relatime/noatime.
> 

фу :(

-- 
      Салют, /GLeb

UIN: 15341920
jabber://gleb@asd.iao.ru
sip://2387245@sipnet.ru			(telephony)
skype://gleb_kulikov.tomsk		(telephony)
sip://20000204@sip.pctel.ru		(telephony)

Re: [Comm] ядро 2.6.30 и xfs

[Michael Shigorin]

On Thu, Dec 03, 2009 at 03:32:29PM +0600, Gleb Kulikov wrote:
> > УМВР, но для ноутов XFS не могу рекомендовать -- kernel
> > thread'ы генерируют дополнительные wakeup'ы.  
> Ну... сложный вопрос. С другой стороны, агрессивное кеширование
> в памяти очень полезно для медленных бучных винтов и особенно,
> их живого пользователя.

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

> > Если вылизывать машинку, то придётся возвращаться на
> > ext3+relatime/noatime.
> фу :(

Ладно, imho.  BTW на jfs для буков никто не смотрел?

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

Re: [Comm] ядро 2.6.30 и xfs

[Yura Kalinichenko]

Michael Shigorin пишет:
> BTW на jfs для буков никто не смотрел?
Мне лично jfs всё больше нравится:
- скорость чека просто феноменальная как для юниксовых FS;
- устойчивость (по кр. мере на kernel 2.6.26) - тоже выше всяких похвал: 
мне так и не удалось ее завалить играми с элекропитанием, в отличие от 
ext3 и xfs.
- скорость работы с большими каталогами весьма хороша

Недостатки все больше гипотетические:
- на ядрах 2.4 было _очень_ глючное. Не скоро забуду удаленное 
переливание полуживой jfs на ext3 на работающем сервере под Master'ом 
2.4 ...
- по слухам, при очень сильнонагруженной работе с БД (Postgre), у людей 
имела место потеря данных. Правда, версия ядра была хоть и 2.6, но 
где-то в районе 18 если не меньше. И мне это на моих задачах пока 
повторить не удалось. Хотя может быть потому, что создать нагрузку о 
которой шла речь - достаточно непросто.

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

Ах да, еще один недостаток: инсталлер от ALT не позволяет 
отформатировать в jfs, а свежеустановленная система не содержит 
jfsutils, даже если была таки поставлена на jfs. Я-то без этого 
обхожусь, а вот средний пользователь бука - вряд ли.

-- 
SY, 
   Yura Kalinichenko

Re: [Comm] ядро 2.6.30 и xfs

[Denis Nazarov]

В сообщении от Четверг 03 декабря 2009 23:16:28 автор Yura Kalinichenko 
написал:
> Michael Shigorin пишет:
> > BTW на jfs для буков никто не смотрел?
> 
> Мне лично jfs всё больше нравится:
> - скорость чека просто феноменальная как для юниксовых FS;
> - устойчивость (по кр. мере на kernel 2.6.26) - тоже выше всяких похвал:
> мне так и не удалось ее завалить играми с элекропитанием, в отличие от
> ext3 и xfs.
> - скорость работы с большими каталогами весьма хороша
> 
> Недостатки все больше гипотетические:
> - на ядрах 2.4 было _очень_ глючное. Не скоро забуду удаленное
> переливание полуживой jfs на ext3 на работающем сервере под Master'ом
> 2.4 ...
> - по слухам, при очень сильнонагруженной работе с БД (Postgre), у людей
> имела место потеря данных. Правда, версия ядра была хоть и 2.6, но
> где-то в районе 18 если не меньше. И мне это на моих задачах пока
> повторить не удалось. Хотя может быть потому, что создать нагрузку о
> которой шла речь - достаточно непросто.
> 
> Так что на сервера ставить пока побаиваюсь, но если рассматривать
> применение для буков и рабочих станций - то IMHO должно быть самое оно.
> 
> Ах да, еще один недостаток: инсталлер от ALT не позволяет
> отформатировать в jfs, а свежеустановленная система не содержит
> jfsutils, даже если была таки поставлена на jfs. Я-то без этого
> обхожусь, а вот средний пользователь бука - вряд ли.
> 
а можно динамически менять размеры разделов, например, в gparted? XFS такого 
не позволяет, в отличие от ext3

Re: [Comm] ядро 2.6.30 и xfs

[Yura Kalinichenko]

Denis Nazarov пишет:
> а можно динамически менять размеры разделов, например, в gparted? XFS такого 
> не позволяет, в отличие от ext3
Насчет gparted - не знаю, не пользую, но вот man mount что говорит:

Mount options for jfs
...
       resize=value ...



-- 
SY, 
   Yura Kalinichenko

Re: [Comm] ядро 2.6.30 и xfs

[Michael Shigorin]

On Thu, Dec 03, 2009 at 11:24:40PM +0500, Denis Nazarov wrote:
> а можно динамически менять размеры разделов, например, в
> gparted? XFS такого не позволяет, в отличие от ext3

Позволяет, но только вверх -- уменьшаться штатно не умеет.

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

Re: [Comm] ядро 2.6.30 и xfs

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

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

On Thu, Nov 26, 2009 at 04:11:23PM +0600, Gleb Kulikov wrote:

GK> У меня традиционно XFS, всего больше 2 десятков машин. Проблем замечено не 
GK> было (кроме описанных с kde при жёсткой перезагрузке, очень уж агрессивно кде 
GK> переписывает вои файлы конфигурации).
GK> PS: мне понравилось держать важное из ~/.kde* в git :)

У меня вообще весь ~/ в git :)

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

http://freesource.info
----------------------------------------------------------------------------

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

Re: [Comm] ядро 2.6.30 и xfs

[alisher]

В сообщении от Воскресенье 06 декабря 2009 23:56:12 автор Денис Смирнов 
написал:
> On Thu, Nov 26, 2009 at 04:11:23PM +0600, Gleb Kulikov wrote:
> 
> GK> У меня традиционно XFS, всего больше 2 десятков машин. Проблем замечено
>  не GK> было (кроме описанных с kde при жёсткой перезагрузке, очень уж
>  агрессивно кде GK> переписывает вои файлы конфигурации).
> GK> PS: мне понравилось держать важное из ~/.kde* в git :)
> 
> У меня вообще весь ~/ в git :)
> 
А можно ссылку где почитать, в чем преимущества такого подхода?

Re: [Comm] ядро 2.6.30 и xfs

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

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

On Mon, Dec 07, 2009 at 10:12:51AM +0600, alisher wrote:

a> А можно ссылку где почитать, в чем преимущества такого подхода?

Ссылки нет -- я ничего такого не видел.

Преимущества для меня очень простые:

1. У меня есть история всех моих изменений в конфигах с момента введения
этого подхода.
2. Как следствие -- мне не нужно хранить несколько бэкапов конфигов (типа
вчерашний, недельный, месяц и т.д.) -- если у меня есть последний бэкап,
значит у меня есть вся история
3. Вероятность убить важные данные минимально. Потеряться может только то,
что появилось после очередного коммита. Коммиты делаются как вручную, так
и по cron'у.

Недостатки:
- не стоит класть конфиги и данные в 1 git repo, приходится вдумчиво
  создавать несколько репозиториев в ~/
- документы от openoffice это zip-архивы. Соответственно если у меня было
  10 версий документа -- хранятся все 10 версий. Если в документе было
  много картинок, и документ получается в несколько мегабайт - съедаются
  уже десятки мегабайт, это очень плохо
- всегда есть каталоги, где происходит особо кипучая деятельность (с теми
  же документами), вместе с предыдущим пунктом такой репозиторий может расти
  на десятки мегабайт в день. В общем-то мне дискового пространства на
  рабочем компе (в отличии от ноута) совершенно не жалко, ибо терабайтники
  уже стали относительно недорогим ширпотребом, но слишком большой репо
  тормозит.

=> каталоги с такой кипучей деятельностью живут у меня несколько месяцев.
Потом -- репозиторий в архив, и пересоздаю репозиторий (в том же каталоге
с теми же файлами) заново.

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

Еще одна большая проблема -- в UNIX-системах очень удачная логика
хранения системных файлов (/var/spool, /var/run, /usr/share, /etc,
/var/log) -- ясно где что лежит, удобно бэкапить, и т.д.

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

Из-за этого приходится очень вдумчиво писать .gitignore.

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

http://freesource.info
----------------------------------------------------------------------------


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