Пишу оффлайн дефрагментатор reiserfs

Если сформулируешь по-русски, то я могу и на аглицкий перевести.

Ошибок не было, про листья - не скажу, потер лог :(

Ну и как дела? Релиз уже есть?

Ну, вроде дефрагментация без проблем идет, но долго. Использовал на своем же /.

А толк-то есть? На сколько быстродействие возрастает?

Ну и как дела?

Работает «полная» дефрагментация, правда очень медленно, так как двигается всё содержимое. Все метаданные журналируются (часть данных тоже), так что из-за внезапного прерывания ничего не должно пропадать. Сейчас пишу инкрементальную дефрагментацию, думаю над алгоритмом. Как доделаю, напишу сюда. Дальше буду делать часть с выносом файлов в начало диска (в основном, чтобы помочь readahead-fedora).

Релиз уже есть?

Нет, просто ставлю теги. Последний: tree-through-v2.

так что если прервать, ФС наверняка испортится

отлитчная фича!

> так что если прервать, ФС наверняка испортится

Уже нет, так как запилил журналирование. Но OP уже не могу исправить.

На глаз - портаж быстрее синкается/быстрее работает.
Жаль, тесты не догадался провести до дефрага.

Версия v0.1 уже маячит на горизонте :). Осталось сделать косметические изменения: добавить возможность менять параметры через ключи командной строки, возможность менее радикально прерывать дефрагментацию и прочее подобное.

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

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

Сорри за некоторый офтоп, но интересно почему выбор пал на reiserfs? ext4 чем не угодил? На ext4 не замечал никакой фрагментации более 1% (почти 2 года непрерывной работы), заикания отсутствуют даже при бешеной работе винчестера.. Единственный недостаток - довольно большой расход места, а в остальном нареканий не было.

P.S.

Может снижение производительности происходит из-за глючного шлейфа, битых секторов или других аппаратных проблемах? (В это верится больше)

ext4 чем не угодил?

Пишу оффлайн дефрагментатор reiserfs (комментарий)

Пишу оффлайн дефрагментатор reiserfs (комментарий)

Ну и нафиг нужна дефрагментация при 1% фрагментации??)

А, вопрос стоял, в том, почему он не использует ext4? Мне просто сначало показалось, что вы спрашивали про то, почему ТС пилит дефрагментатор именно для reiserfs и на ваше «ext4 чем не угодил» я и привел ответ автора, что в ext4 есть дефрагментатор и его пилить не зачем, так как он работает.

Насчет того, почему просто не использовать ext4 думаю автор лучше ответит. А насчет того, нафига рейзеру дефрагментатор, автор уже все сам пояснил.

МиБ

Мигобайты?

Сорри за некоторый офтоп, но интересно почему выбор пал на reiserfs? ext4 чем не угодил?

У меня есть нетбук, aoa110, в который я вставил жёсткий диск. Он со странностями. Ext4 на нём не работала никак. Зато работали reiserfs, jfs и btrfs. В общем, долгое время там была jfs. На нём образовывалась жуткая фрагментация (а вера в сказку «дефрагментация не нужна» мешала в осознании факта), напрягало. Приходилось дефрагментировать пересозданием ФС с нуля. Попробовал reiserfs, потому что видел заявления, что она устойчива к фрагментации, на неё и остановился. Как выяснилось, устойчивости особой-то и нет. Примерно на одном уровне у всех.

ext4 я потом выяснил как использовать, но тот мелкий патч в fsdevel отвергли, из-за того что он сломает ext4 с 1к блоками на WD Advanced format. Я попытался убедить, что ничего он не ломает, но всё как-то заглохло.

Мигобайты?

http://ru.wikipedia.org/wiki/Двоичные_приставки

Благодарю за пояснение. Походу у Вас масштабная война с аппараткой. Но вопрос 2-х годичной давности - может уже поправили код на ext4? С тех пор много изменений было.

может уже поправили код на ext4? С тех пор много изменений было.

Нет, конкретно это место не исправляли. Да и я уже сомневаюсь, что это правильно и стоит править код. Тем более, теперь нетбук лежит на полке.

Ааааа, человече! Сделай тег! Я хоть пакет тогда запилю...

Сделай тег!

Плохая идея, это ведь work-in-progress версия. Я её вывалил только потому что это за последние почти три недели первая версия без глюков. Даже не знаю, как её называть. Тем более у меня уже определился список задач, которые надо выполнить, чтобы я со спокойной совестью мог поставить метку v0.1. Хочу поскорее дотуда добраться, отложил уже все фичи, которые можно было отложить.

ну, ок , убедил :-)
а changelog у 0.1 будет, да ведь?

а changelog у 0.1 будет, да ведь?

Ага, обязуюсь написать.

Понятно. Что касается оптимизации фс я немного в другом направлении размышлял. Зачем дефрагментировать, если можно заранее выполнить упаковку слоев каскадной фс так, чтобы загрузка приложений или системы происходила близко к оптимальной? Возможно таким образом получится ускорить запуск «холодных» приложений. Корень на squashfs+aufs ведет себя очень неплохо - система загружается и работает отнюдь не медленнее несжатой при огромной экономии места. 3,5 Гб оптимизированной системы укладываются в 1,2 Гб squashfs при lzo (быстрее нежели xz) сжатии и в 700+ Мб с использованием xz. Есть наверно некоторые изъяны в моей реализации initramfs. Например, при отмонтировании фс система ругается, что действие недоступно, однако ошибки на диске отсутствуют. Как побороть это пока не нашел.

Для 3 или 4?

Для 3 или 4?

3

Четвертый вроде нестабилен?

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

Я слышал подобные этому идеи: каждое приложение (пакет) упаковать в кусок ФС, а при установке просто цеплять их. Установка программ будет происходить очень быстро — это всего лишь запись одного большого файла. Вроде об этом говорила Valerie Aurora в обзорной статье про unionfs. Правда она впоследствии отказалась от дальнейшего развития идеи.

Корень на squashfs+aufs

Я пробовал так, мне понравилось, но обновления довольно хлопотны.

Большая уважуха за смелость и медаль за достижения!

каждое приложение (пакет) упаковать в кусок ФС, а при установке просто цеплять их

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

обновления довольно хлопотны.

Есть малость) Упаковка 3,5 гигов занимает минут 40 на атоме, ежели в один сквош закидывать. Как вариант тоже разбить корень на отдельные куски, которые обновлять независимо.

А вот сервер на ext3 у меня однажды умер безвозвратно (ФС не восстановилась) без какой-либо посторонней симптоматики, просто при работе. Так что, может, у ext4 это генетическое?

У меня ntfs один раз так умерла. Мало ли что сбойнуло. Может, какой-нибудь нестабильный бит в RAM привел к неверному ветвлению или же контроллер увидел команду записать 100 секторов вместо 1. «От неизбежных на море случайностей.»

Может, какой-нибудь нестабильный бит в RAM привел к неверному ветвлению

Чтобы вся ФС умерла? Ну, вероятность, наверное, не нулевая, но… :)

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

У меня подошло время обновления личной сборки gentoo. Набежало около 300 более менее серьезных пакетов. Решил провести мероприятие не на разделе ext4, а на reiserfs. Распаковал образ squashfs на него и запустил обновление из chroot. Решил посмотреть 2-х часовой фильм (на разделе /home с ext4) через mplayer. Загрузка процессора (atom N270) была 100% из них около 15% расходовал mplayer. Причем компиляция в этот раз была запущена мною всего в 4-ре потока. В процессе просмотра получил несколько заиканий и замедление отклика на мои действия, чего никогда не наблюдалось даже близко, если обновлялся на разделе ext4 и в 12 потоков (наследство от использования распределенной компиляции, которое совсем не тормозило работу на компьютере даже при компиляции непосредственно на нетбуке).

Стечение обстоятельств или такие подтормаживания выдает подсистема reiserfs? Больше похоже на второе.

Для 3 или 4?

может пора запомнить, что grub-2.* это grub2, reiserfs - это 3.6 и прочие...

как прогресс?
на файлопомойке можно уже погонять?

МиБ

... :) По госту 8.417-2002 сделать была не судьба? Хотябы в локализации.

Уже не надо, вот оно как на самом деле дожили. маркетолаги йопт.

По госту 8.417-2002 сделать была не судьба?

смотри сноски 2 и 3 в таблице А.1 приложения А к ГОСТ 8.417-2002.

CD(R) и Floppy забыли в табличке. Думаю, специально, ибо сразу будет видно маркетоложество на переходе CD -> DVD.

как прогресс?

Добавил корректный останов по Ctrl-C. Программа стала немного более разговорчивой. Доделываю до состояния, в котором смогу повесить ярлык v0.1. Осталось написать changelog, написать краткую справку (usage) для показа по --help и поправить глюк с аллокатором в ФС с размерами не кратными 128 МиБ. Если у тебя такая ФС, лучше не запускай :) Думаю, починить — часа два-три займёт.

на файлопомойке можно уже погонять?

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

На низком уровне есть проверки (и я планирую сделать ещё больше позже), которые призваны спасти от несуразных ошибок на алгоритмов верхних уровней . Эти проверки уже помогали, да, спасли мне /var :)

или такие подтормаживания выдает подсистема reiserfs?

Я тут недавно ради интереса глазел в вывод perf top при работе с разделом reiserfs. И обнаружил, что самая горячая функция — бинарный поиск ключа. А самая горячая точка в этой функции — idiv. В общем, это довольно медленная операция. На Core2 она два порта занимает. Что самое интересное, деление происходит на 2, то есть компилятор мог вполне сделать это сдвигом, но почему-то выбрал сделать именно так. Сдвиг занимает один порт на Core2 и может быть слит с другими командами.

Может, это можно патчем поправить? Тот кусок на ассемблерную ставку заменить.

Мне туда боязно соваться. Работает — и ладно.

Можно, в принципе, Шишкину написать в мейл-лист.

За двумя зайцами погонишься...

Ну, я думаю, если им в мейл лист отписаться с результатами perf'a и 2-мя строчками рассуждений - будет достаточно. Сделают хорошо, не сделают... как был рейзер на /, так и будет.

Получается этот кусок хандрит?

static inline int bin_search(const void *key,	/* Key to search for. */
			     const void *base,	/* First item in the array. */
			     int num,	/* Number of items in the array. */
			     int width,	/* Item size in the array.
					   searched. Lest the reader be
					   confused, note that this is crafted
					   as a general function, and when it
					   is applied specifically to the array
					   of item headers in a node, width
					   is actually the item header size not
					   the item size. */
			     int *pos /* Number of the searched for element. */
    )
{
	int rbound, lbound, j;

	for (j = ((rbound = num - 1) + (lbound = 0)) / 2;
	     lbound <= rbound; j = (rbound + lbound) / 2)
		switch (comp_keys
			((struct reiserfs_key *)((char *)base + j * width),
			 (struct cpu_key *)key)) {
		case -1:
			lbound = j + 1;
			continue;
		case 1:
			rbound = j - 1;
			continue;
		case 0:
			*pos = j;
			return ITEM_FOUND;	/* Key found in the array.  */
		}

	/* bin_search did not find given key, it returns position of key,
	   that is minimal and greater than the given one. */
	*pos = lbound;
	return ITEM_NOT_FOUND;
}

Сам алгоритм нужно улучшать или ну нафиг этот reiser?

P.S.

Если я правильно посмотрел, то кроме деления на два можно еще кусок

j * width

s = s + width

P.S.

Чую, если заняться, то от исходного кода ничего не останется... Сразу как то не по себе становится.

Получается этот кусок хандрит?

Не уверен. Он действительно инлайнится и такой функции в коде нет. Профайлер показывает на search_by_key. Моих знаний x86 не хватает, чтобы свободно ориентироваться в таких здоровых функциях.

Сам алгоритм нужно улучшать

Не думаю, что есть что-то лучше бинарного поиска.

Я лучше опишу непосредственные наблюдения, чтобы кто-то ещё мог сделать выводы. Я копировал на 1g раздел дерево исходников ядра. В search_by_key попало 2.3% всех семплов. 20% их них — на следующую за idiv инструкцию (это был movq).

Нафиг здесь умножать или тут не прав?

Умножения относительно дешёвые, насколько я знаю. По крайней мере, в коде активно умножается на 0x18 и семплов рядом с imul почти нет.

Чую, если заняться, то от исходного кода ничего не останется

Вот и я не спешу по той же причине. Выигрыш копеечный, а сил придётся положить много. Ещё и код станет хуже читаемым.

А самая горячая точка в этой функции — idiv. В общем, это довольно медленная операция. На Core2 она два порта занимает. Что самое интересное, деление происходит на 2, то есть компилятор мог вполне сделать это сдвигом, но почему-то выбрал сделать именно так.

idiv ведь делит знаковое. Их сдвигом не поделишь на два. Посмотри, например, что получится при сдвиге вправо -1 = 0xffffffff. Явно не ноль, даже если знаковый бит запоминать и восстанавливать.

idiv ведь делит знаковое. Их сдвигом не поделишь на два.

Есть знаковый сдвиг: sar %rdx, например.

Что-то мне подсказывает, что там вряд ли появятся отрицательные числа