2 KRoN73: reiser4

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

// wbr

При создании с компрессией gzip1 - та же самая херня.

Я в сомнениях, пью вино и размышляю о странностях современных ФС :(

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

Я слишком долго ждал.

P.S. виноделы как-то умудряются за год отладить свежий билд до состояния кошерности. А в бывшем Namesys одни трезвенники чтоль?

> P.S. виноделы как-то умудряются за год отладить свежий билд до состояния кошерности. А в бывшем Namesys одни трезвенники чтоль?

далеко не всякий.

// wbr

>А в бывшем Namesys одни трезвенники чтоль?

А бывший namesys жив?

> далеко не всякий.

Но те кто умеет - каждый год стабильно это осиливают. А иногда и улучшают.

Выходит, что хорошо выдержанная ext3 -> ext4 более кошерна? ;)

> Выходит, что хорошо выдержанная ext3 -> ext4 более кошерна? ;)

ну а ты сам то как считаешь? :)

// wbr

> ну а ты сам то как считаешь? :)

Да мне пофиг, если честно, но прозрачная компрессия у reiser4 впечатляет ;)

А так - рулит ext3, как и раньше рулила. Для толстых хранилищ - jfs/xfs по вкусу.

> Да мне пофиг, если честно, но прозрачная компрессия у reiser4 впечатляет ;)

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

> А так - рулит ext3, как и раньше рулила. Для толстых хранилищ - jfs/xfs по вкусу.

ну вот видишь, ты и сам все прекрасно знаешь.

// wbr

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

Не всё так просто.

> ну вот видишь, ты и сам все прекрасно знаешь.

А ну как треба считать инфы на 1.5 терабайта, которая на одной ФС упакована в 100 метров, а на другой - в полном размере лежит? ;)

> А ну как треба считать инфы на 1.5 терабайта, которая на одной ФС упакована в 100 метров, а на другой - в полном размере лежит? ;)

не совсем понял проблему, если честно. ну возьми да считай :-?

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

// wbr

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

А я удивлён, что не понимаешь: CVS/SVN - это ли не пример, дядь? ;)

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

P.S. сорцы некоего продукта, практически в plain-text, к которому у меня был доступ, чекаутились с CVS порядка 4-5 часв, по гигабитным линкам (оно самое), на пачку сервиров сборки.

Считать? :)

А где можно почитать про эту компрессию?

> А я удивлён, что не понимаешь: CVS/SVN - это ли не пример, дядь? ;)

хостить для дома для семьи cvsroot за последние десять лет, скажем, FreeBSD? кхм.

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

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

> P.S. сорцы некоего продукта, практически в plain-text, к которому у меня был доступ, чекаутились с CVS порядка 4-5 часв, по гигабитным линкам (оно самое), на пачку сервиров сборки.

ну заняли они, кажем, 500Gb. ну и что? не хватило - поставь ещё 500 а лучше сразу полтора.

// wbr

На LOR-wiki.

> хостить для дома для семьи cvsroot за последние десять лет, скажем, FreeBSD? кхм.

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

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

А если отвлечь от прошитых паттернов и поразмыслить над концептом? Хорошо же, правильно и красиво, йопт! ;)

> ну заняли они, кажем, 500Gb. ну и что? не хватило - поставь ещё 500 а лучше сразу полтора.

А липездричество? А место в стойке? Копеечка к копеечке - и рублик сбережёт. А мы потом на него Калифорнию обратно выкупим, дядя ;)

> А если отвлечь от прошитых паттернов и поразмыслить над концептом? Хорошо же, правильно и красиво, йопт! ;)

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

> А липездричество? А место в стойке? Копеечка к копеечке - и рублик сбережёт.

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

> А мы потом на него Калифорнию обратно выкупим, дядя ;)

да нужна она кому.

// wbr

Я компрессию не юзал.

>ну да, а сжатие/разжатие - оно волшебным образом даётся

iowait ниже будет. Начиная с какого-то соотношения трансфера винта и скорости CPU сжатие начинает приводить к повышению производительности дисковой подсистемы. Уже лет 15 как Stacker в народ пошёл и с этим явлением на практике столкнулись :)

Гхарег, ты же не думаешь, что в том порнокладезе хранятся только порнотексты и ASCII art? А картинки и фильмы жмутся крайне плохо.

>фильмы жмутся крайне плохо.

Под фильмы по-любому лучше xfs :) А вот для всяких /usr или /home reiser4 сразу после установки (и без компресии) - лучший. Правда, со временем портится :) (см. соответствующую тему).

> Я компрессию не юзал.

Т.е. без компрессии всё нештяк?

А со временем? Если рейзер3 себя самобалансирует и хвосты пакует во имя недопущения бардака, но рейзер4 таки деградирует по истечении некоего срока?

> Под фильмы по-любому лучше xfs :)

Реально? А пофиг. Битрейт до 50х2х2мбит даст любая ФС на любом современном носителе. На рейде - тем более, а количество траха в случае !xfs может быть поменьше.

У меня был случай, когда энтерпрайз-БП и энтерпрайз-ИБП (с пачкой запасных баратей, сутки работы, все дела) тотально не дружили и сервак таки падал время от времени - просто на ровном месте, без логов, раз в 2 месяца ровно и т.п.

Притом, всё было брендовое по самые яйца и железо менялось не раз - для проверки. А ручная перезагрузка раз в 1.95 месяца отлично помогала. И ХЗ что это такое было...

Наверное это та же самая карма, что и у тебя с XFS, чисто чтоб не расслябляться ;)

>Т.е. без компрессии всё нештяк?

По сравнению с другими FS без компрессии всё превосходно. А на счёт Reiser4 vs Reiser4 с компрессией - не сравнивал.

>рейзер4 таки деградирует по истечении некоего срока?

Не знаю, с чем это связано, со внутренними проблемами FS или с фрагментацией (хотя на тестах я фрагментацию создавал и всё равно там Reiser4 себя отлично вёл), но факт - через пару месяцев (или сколько я там его юзал?) /usr на reiser4 стал безбожно тормозить. Перенос чере cp на другую партицию с той же reiser4 ситуацию исправляет. Конвертация текущей партиции в xfs и копирование данных на неё (т.е. данные те же, физически раздел в том же месте, только FS другая) тоже всё оживляет... Так что /usr у меня на этой машине сейчас в XFS. На другой пока в Reiser4, там итак работает нормально (машина используется менее интенсивно, да и памяти 4Гб, тоже м.б. сказывается).

>Реально? А пофиг. Битрейт до 50х2х2мбит даст любая ФС на любом современном носителе.

Битрейт битрейту рознь, а вот онлайновый дефраг xfs очень здорово жизнь облегчает :) А то вот: http://www.linux.org.ru/jump-message.jsp?msgid=3250893&cid=3251719

...

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

> Битрейт битрейту рознь, а вот онлайновый дефраг xfs очень здорово жизнь облегчает :) А то вот:

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

> И, особенно, если фильмы не просто хранить, а в несколько потоков раздавать, то многие FS на сильной фрагментации начинают столь же сильно тормозить.

Хардовый рейд на 8-12 винтов осилит любой канал. 4х1Gbit и кучу юзеров осиливает легко, по крайней мере, уже больше 2-х лет без особого апгрейда дисковой.

ХЗ, наверное тормозная вендо-самба виновата.

> По сравнению с другими FS без компрессии всё превосходно. А на счёт Reiser4 vs Reiser4 с компрессией - не сравнивал.

Там всё великолепно: экономия места на текстовиках колоссальная ;)

Раздел с десятком копий сорцов ядра занимает на диске физически порядка 300-400 мегов, тогда как на ext3 - далеко за пару гигабайт. Скорость доступа соответствующая.

> Не знаю, с чем это связано, со внутренними проблемами FS или с фрагментацией (хотя на тестах я фрагментацию создавал и всё равно там Reiser4 себя отлично вёл), но факт - через пару месяцев (или сколько я там его юзал?) /usr на reiser4 стал безбожно тормозить. Перенос чере cp на другую партицию с той же reiser4 ситуацию исправляет. Конвертация текущей партиции в xfs и копирование данных на неё (т.е. данные те же, физически раздел в том же месте, только FS другая) тоже всё оживляет... Так что /usr у меня на этой машине сейчас в XFS. На другой пока в Reiser4, там итак работает нормально (машина используется менее интенсивно, да и памяти 4Гб, тоже м.б. сказывается).

Чипсет Nvidia? Либо... NCQ включён?

> Почему при создании с компрессией lzo1

Ну вот так мир устроен... У меня та же фигня.

> А на счёт Reiser4 vs Reiser4 с компрессией - не сравнивал.

Скорость выше, бенчмарки есть в гугле. Единственное - глаза мусолят эти wrong bytes или как-то так в fsck.reiser4.

Я юзал и lzo1, и gzip1. В конце выбрал gzip, ибо незаметный табличный выигрышь в скорости от lzo не очень-то контрастирует с в разы более быстрым поеданием дискового пространства.

> Чипсет Nvidia? Либо... NCQ включён?

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

>Хардовый рейд на 8-12 винтов осилит любой канал.

А ещё лучше 8-12 SSD-шек. Ага.

>Чипсет Nvidia?

i865

>Либо... NCQ включён?

# hdparm -I /dev/sda /dev/sdb /dev/sdc|grep -i ncq
           *    Native Command Queueing (NCQ)
           *    Native Command Queueing (NCQ)
           *    Native Command Queueing (NCQ)

> i865

Значить то косяк системный.

> # hdparm -I /dev/sda /dev/sdb /dev/sdc|grep -i ncq
> * Native Command Queueing (NCQ)

Да не про "есть", я про "включён" ;)

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

Дело доходило до деградации с 80M/s до 1-2M/s на линейном чтении после записи большого файла на низкой скорости.

> Я юзал и lzo1, и gzip1. В конце выбрал gzip, ибо незаметный табличный выигрышь в скорости от lzo не очень-то контрастирует с в разы более быстрым поеданием дискового пространства.

Но оно по сохранности данных как? А то слегка парит видеть эти "вронг байтыз".

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

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

> Скорость выше, бенчмарки есть в гугле.

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

> А ещё лучше 8-12 SSD-шек. Ага.

Не поверишь... но не лучше! ;)

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

Оно мне нахер такое надо за на порядок большие деньги? ;)

Лучше кэш поставить гигов на 16-64 из честной оперативы, благо техника нонешняя такое легко позволяет. Выйдет этакий хардварный мега-контроллир за сравнимые деньги, но несравнимо более надёжный.

>> Я юзал и lzo1, и gzip1. В конце выбрал gzip, ибо незаметный табличный выигрышь в скорости от lzo не очень-то контрастирует с в разы более быстрым поеданием дискового пространства.

> Но оно по сохранности данных как? А то слегка парит видеть эти "вронг байтыз".

Оно впоряде. Я кручу субж на ноуте третий год на пролёт - ни разу ничего в lost+found не наблюдал. И сейчас нет. Раньше реально очковал, когда fsck требовал указывать --build-fs, потому что major corruptions и т.д. В продакшен рекомендовать сильно не стану, в первую очередь из-за спада скорости.

Ещё рекомендую переключать консоль с fsck.reiser4 на другую - оно пишет много debug-мессаг, что реально жрёт проц и в пределе вызывает wait на винче. В VESA-режимах это существенно замедляет проверку. Утверждение доказывается наблюдением за HDD-светодиодом.

Ещё брешь: если один раздел с Reiser4 смонтирован, а второй на проверке, то у меня несколько раз появлялись повреждения на первом. Полтергейст конечно, но всё же осадок остался.

Статью в lor:wiki я написал, там в общем-то это всё описано.