LINUX.ORG.RU

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

 ,


8

9

Собственно, уже написал.

На данный момент он дорос до версии v0.2.2 и в нём реализовано всё, что я собирался реализовывать. Код здесь: https://github.com/i-rinat/reiserfs-defrag/archive/v0.2.2.tar.gz

В плане сохранности данных реализовано журналирование как метаданных, так и самих данных (нужно включить, указав параметр командной строки). Сама схема журналирования похожа на data=ordered в ext3/4, когда сначала пишутся данные, а только потом происходит обновление метаданных. Актуальные данные никогда не переписываются на месте, всегда происходит копирование на пустое место. Это снижает производительность, но значительно снижает вероятность повреждения. Собственно, сейчас повреждения возможны только если диск сойдёт с ума и начнёт писать куда не просили. По крайней мере, мне нравится так думать.

В составе есть краткая документация.

В далёком будущем появится версия v0.3, в которой ожидаются убавление тормозов в режиме tree-through и улучшение производительности для больших директорий.

★★★★★

Последнее исправление: i-rinat (всего исправлений: 3)

Ответ на: комментарий от i-rinat

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

Они есть, но должны учитывать специфику обрабатываемых данных. В бинарном поиске не учитываются эвристики. К примеру, не берутся в расчет производные искомой функции, которые позволяют достаточно быстро приближаться к решению (метод хорд-секущих). Сложность sqrt(O) это гуд, но часто это далеко не предел. Иногда поиск удается свести к логарифмической сложности или вообще к O(1) сбором дополнительных данных в процессе работы программы.

Насколько я понял reiserfs целиком базируется на деревьях, а если еще учесть, что они должны балансироваться для обеспечения хорошей производительности и что любое изменение данных в этот момент заставит повторно заниматься той же процедурой. Получается сложность алгоритма как минимум sqrt(O)*Коэф. Не думаю, что это самое лучшее решение. Про фрагментацию даже не вспоминаем.

P.S.

Это просто точка зрения - ничего более

glibych ★★
()
Ответ на: комментарий от i-rinat

Юров пишет, что остаток (при делении idiv) всегда имеет знак делимого. Т.о. для idiv будет -1 = 0*2 + (-1), а для sar -1 = -1*2 + 1. Т.е. sar не эквивалентно idiv 2.

d ★★★★
()

Выпустил v0.1. Из видимых изменений можно отметить инкрементальный алгоритм дефрагментации и прогрессбары.

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

Ещё одно серьёзное изменение: можно использовать ctrl-c для прерывания. Сигнал перехватывается и программа постарается доделать текущие дела (которые нельзя отложить) и выйти, оставив ФС в непротиворечивом состоянии. Теперь выход будет дольше, но так спокойнее.

P.S. Есть ChangeLog.

i-rinat ★★★★★
() автор топика
Последнее исправление: i-rinat (всего исправлений: 1)

Чтобы разрабатывать для reiserfs нужно вначале жениться.

soomrack ★★★★
()
Ответ на: комментарий от i-rinat

О! Завтра запилю в оверлей :-)
P.S. Спасибо за Ch-log

tis ★★
()
Ответ на: комментарий от unC0Rr

А нет ли желания сделать такую же штуку и для других ФС? Или тут уже энтузиазма не хватит?

Если сейчас начну, через полтора года возможно появится первый результат :)

Кстати, пользуясь случаем, хочу упомянуть недостаток в текущей реализации: программа двигает метаданные копированием, не затирая старое местоположение. У меня есть опасения, что старые метаданные могут смутить rebuild-tree. Не знаю пока, как с этим быть, затирать или забить.

i-rinat ★★★★★
() автор топика
Ответ на: комментарий от i-rinat

i-rinat

затирать или забить

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

unC0Rr ★★★★★
()

Нашёл неприятный глюк — если сделать терминал слишком узким (примерно 32 символа), прогрессбар сходит с ума и подвешивает программу. Поправил в master.

i-rinat ★★★★★
() автор топика

Прогнал на нетбуке, чуда не произошло. Было 135 секунд от начала загрузки ядра до окончания дёргания диска, стало 125 секунд.

i-rinat ★★★★★
() автор топика
Ответ на: комментарий от i-rinat

а портаж на вскидку быстрее работает/обновляется....

tis ★★
()

Смотрел на распределение чтений с диска — они синхронные. Получилась такая картинка: http://ompldr.org/vZzkzMw/read-pattern-11G-root.png (32000x4000 px, 2.4MB)

Активные чтения в самом начале — первоначальный сбор данных. Вертикальные линии вдоль времени это, скорее всего, обновления индекса.

i-rinat ★★★★★
() автор топика

Добавил sys-fs/reiserfs-defrag-0.1 в stuff оверлей. Так что гентушники могут попробовать.

tis ★★
()
Ответ на: комментарий от tis

Спасибо.

Есть просьба: можешь убрать DCMAKE_BUILD_TYPE=Release ? А то я потом осознал, что в Release все assert'ы отключаются, но их хорошо бы иметь включенными. Я уже это поправил, но передвигать метку не хотелось бы. Так что если есть возможность, конфигурируй примерно так:

CXXFLAGS="-O2" cmake ..

i-rinat ★★★★★
() автор топика
Ответ на: комментарий от greenman

Изменить?

Нет, в README правильно написано, и в PKGBUILD тоже (я глянул). Менять не надо.

И нужно ли указать «disable stripping of executable»?

Нет необходимости. В коде нет ничего зависящего от наличия или отсутствия отладочной информации.

i-rinat ★★★★★
() автор топика

Молодец! Я, конечно, не гуру в C++, но вот что пишет Страуструп по поводу макросов:

не используйте их без крайней необходимости. Почти что каждый макрос свидетельствует о наличии слабых мест в языке, программе или программисте. Механизмы const, inline, template, enum и namespace являются альтернативой традиционному использованию препроцессорных конструкций.

puding
()
  • Добавил простые проверки (уровень, свободное место, порядок ключей) метаданных при их чтении с диска, для спокойствия. Потенциально это должно находить нестыковки ещё раньше.
  • Журналировать теперь можно и данные тоже.
  • Добавил сортировку при перемещении блоков данных, что при журналировании только метаданных должно давать небольшой прирост в скорости.
i-rinat ★★★★★
() автор топика

Ты женат? Если да, то жена знает?

Ttt ☆☆☆☆☆
()
Ответ на: комментарий от tis

Нет, это промежуточная версия. Нужно ещё сделать обработку файлов по имени, и будет v0.2.

i-rinat ★★★★★
() автор топика

Поменял версию на v0.2. https://github.com/i-rinat/reiserfs-defrag/archive/v0.2.tar.gz

Теперь можно:

  • указать, какие файлы передвинуть в начало раздела. Задаётся параметром командной строки -f <имя-файла-со-списком>. Работает только с инкрементальным дефрагом (выбран по умолчанию). Размещать будет в порядке списка. Мелкие файлы, которые лежат прямо в метаданных, от этой опции ускользают, так как непонятно, как их вообще двигать;
  • сделать кеш блоков побольше. Возможно это улучшит производительность. (Параметр -c <размер-кеша-в-мегабайтах>).

Осталось сделать:

  • дефрагментацию больших директорий;
  • man page;
  • метод tree-through менее тормозным (стараться выделять место сплошными кусками, а не как придётся);
  • преимущественное размещение сегментов файлов рядом друг с другом (сейчас они могут оказаться в разных частях раздела);
  • опциональную очистку старых положений листьев (это уж очень вряд ли);
  • поддержку шаблонов размещения файлов, например видео-файлы в конец раздела (и это тоже вряд ли).
i-rinat ★★★★★
() автор топика
Ответ на: комментарий от unC0Rr

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

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

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

i-rinat ★★★★★
() автор топика
Ответ на: комментарий от i-rinat

Он работает. Что в нём пилить?

Консолидацию свободного пространства, группировку файлов по частоте использования. Да и просто баг периодически всплывает, когда после дефрага до перемонтирования часть свободного места не возвращается.

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

Консолидацию свободного пространства, группировку файлов по частоте использования.

Там это невозможно. Нужна соответствующая поддержка в ядре.

Ну и я могу только оффлайн, и только для reiserfs :)

i-rinat ★★★★★
() автор топика
Ответ на: комментарий от i-rinat

и только для reiserfs :)

Это я прокомментировал конкретно по ext4 дефрагу вопрос :) К тому, что он не совершенен.

KRoN73 ★★★★★
()
Ответ на: комментарий от i-rinat

На твоей страничке нa github'eпишут, что reiserfs-defrag Last updated 18 hours ago

а в списке коммитов: i-rinat authored 13 days ago.

и выкачивается у меня старый, 13-дневный реп.

tis ★★
()
Ответ на: комментарий от tis

Упс, я тег выгрузил, а коммиты пропустил. Исправил.

Только у меня на нетбучном корне какой-то глюк обнаружился с перемещением файлов в начало. Видимо что-то не учёл, и оно пока не работает. Сейчас проверяю, где ошибка.

Собственно, ничего страшного нет, программа просто не будет двигать блоки файлов. (Проверок на ошибки я ещё больше добавил.)

i-rinat ★★★★★
() автор топика
Ответ на: комментарий от tis

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

В общем, теперь это v0.2.1: https://github.com/i-rinat/reiserfs-defrag/archive/v0.2.1.tar.gz

Заодно обновил README.md, в списке файлов теперь удаляются дубликаты, добавил правило для install (в <PREFIX>/sbin) и поменял имя бинарника на reiserfs-defrag.

i-rinat ★★★★★
() автор топика
Ответ на: комментарий от tis

В 0.2 глюк так и остался. Он не фатальный, просто будет ругаться на разреженные файлы и пропускать их.

i-rinat ★★★★★
() автор топика

У меня добавилось score и по этому поводу я обновил начальный пост, указав актуальную информацию. А в master добавилась man page.

i-rinat ★★★★★
() автор топика

Добавил ебилд на 0.2.1 в главное дерево портажей Gentoo

Pinkbyte ★★★★★
()

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

megabaks ★★★★
()
Ответ на: комментарий от megabaks

теперь можно запускать на важных фс?

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

на используемой нормально работает или только из соседней системы?

Нет, только offline. На используемую ругнётся, скажет, что ФС грязная.

что будет если процесс прервать?

По Ctrl-C оно доделает текущий кусочек работы и остановится, закрыв ФС. Если прервёшь жёстко, следующее монтирование штатными средствами (или запуск fsck) проиграет записи в журнале и восстановит целостность. Специально делал для этих случаев журналирование. Используется журнал самой ФС.

i-rinat ★★★★★
() автор топика

Пакетируй и отправляй в debian.

Dron ★★★★★
()
Ответ на: комментарий от i-rinat

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

megabaks ★★★★
()
Ответ на: комментарий от megabaks

а онлайн не планируется?

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

а то мне так не потыкать его на корне

У себя в debian я дописываю в параметры break=premount и получаю консольку до монтирования корня. Потом монтирую, забираю к себе в tmpfs бинарник, отмонтирую и запускаю дефраг. Раз в одну-две недели не так уж и муторно. Один запуск занимает одну-две минуты на 13,5 гиговом корне.

i-rinat ★★★★★
() автор топика
Ответ на: комментарий от megabaks

а долго - это сколько в попугаях?

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

Если запустить с -t tree-through, и сейчас будет долго работать. Относительно быстро работает только -t inc (выбрано по умолчанию).

i-rinat ★★★★★
() автор топика
Ответ на: комментарий от i-rinat

А чего психовать? оно же еще тогда писало в stdout выхлоп работы, раз пишет - значит, работает

tis ★★
()
1 июля 2013 г.

В связи с тенденцией размещать все бинарники в /usr/bin — что нужно указать при сборке, дабы бинарник reiserfs-defrag оказался в /usr/bin, а не в /usr/sbin?

greenman ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.