anyfs-tools 0.84.5

А этот проект когда-нибудь сольется с parted?

Хотел сказать что венде теперь точно конеч нокнец, так нет - восстановят ведь. Хотел подождать ебилдов - фигушки, уже!

Пойду приму яду...

> так нет - восстановят ведь.
Нет, ну что вы? В "венде" NTFS включит шифрование/компрессию на уровне файловой системы и тогда ей уже ничего не поможет ;-)

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

Но в этом случае нужен человек, который будет собственно проталкивать эту идеи в Mail List'ах parted. Потому что моего английского не достаточно.

Кстати, у convertfs были такие же идеи. Никто не знает почему заглохло?

А ещё в мечтах:
идеально было бы, если бы anyfs был включён в ядро, а build_xfs/build_e2fs заменили бы mkfs.xfs/mke2fs в пакетах xfsprogs/e2fsprogs.
Но опять же нужен кто-то кто будет эти идеи проталкивать (но прежде понимать их суть).
Эх.. мечты..

Мечты, мечты... но чем-то сможем помочь.

А даже не чем-то а конкретной идеей.

Для начала хочется доконца проникнуться твоими утилитами и особеностью работы jfs, а то ты ее так деликатно обощел :)

Если заинтересуещься, мыло/jid в профиле, ожидаемс...

Намылил..

> Но в этом случае нужен человек, который будет собственно проталкивать эту идеи в Mail List'ах parted. Потому что моего английского не достаточно.

Мне кажется это не главная проблема. Помочь написать письмо я могу ;-) Я уверен, что главное - это чтобы разработчики/пользователи читающие maillist parted смогли взять твою утилиту по ссылке и попробовать протестировать ее, и если у всех все пройдет гладко и в maillist будут одни только положительные отзывы (я имею ввиду отсутствие повреждений при конвертации, а не, например, скорость работы программы), то комнда parted с радостью тебя примет в свои ряды. Будешь знаменит. Единственное, что может помешать - это PAP (patch acceptance policy). Чаще всего PAP существует у проектов с 1-2 разработчиками, и они хотят, чтобы весь код был их (copyright), но и это можно обойти, сделаешь fork parted, объявишь это в maillist/LOR/freshmeat и люди к тебе потянутся :-) Я сам участвовал в некоторых GPL проектах, в некоторых - пришлось отдавать код (просто запарило каждый раз с выходом новой версии писать свой патч), в некоторых - даже не упомянули меня нигде (не говоря уже про copyright), хотя изменения я делал неплохие... Я думаю если твоя программа так хороша и стабильна, то даже в самом худшем случае твой fork parted будет популярен.

> идеально было бы, если бы anyfs был включён в ядро, а build_xfs/build_e2fs заменили бы mkfs.xfs/mke2fs в пакетах xfsprogs/e2fsprogs.

Вот в этом не уверен. Этот кусок они оставят скорее всего себе. Какие преимущества от такой замены?

> Помочь написать письмо я могу ;-)

Ну, нужно не одно письмо. Лучше чтобы был именно представитель проекта, сам понимающий все преимущества (ну и недостатки разумеется) anyfs-tools. Иначе это будет просто переводчик :-)

> Я уверен, что главное - это чтобы разработчики/пользователи читающие maillist parted смогли взять твою утилиту по ссылке и попробовать протестировать ее, и если у всех все пройдет гладко и в maillist будут одни только положительные отзывы (я имею ввиду отсутствие повреждений при конвертации, а не, например, скорость работы программы), то комнда parted с радостью тебя примет в свои ряды.

Значит нужно тестирование и ещё раз тестирование...

> Вот в этом не уверен. Этот кусок они оставят скорее всего себе. Какие преимущества от такой замены?

Для пользователя? Если найдётся два-три пакета, которые заменят в своих progsfs mkfs на buildfs, то наверняка майнтейнеры и других ФС будут включать в свои progfs buildfs, а поддержка майнтейнерами файловых системы -- это уже надёжность любых таких конверсий файловых систем.
Самим майнтейнерам build_<их fs> может прибавить пользователей.
А что касается замены (а не скажем добавления) -- я старательно везде стараюсь писать, что build_xfs/build_e2fs основан на коде mkfs.xfs/mke2fs. И buildfs -- это расширение возможностей mkfs. Ведь, тот же mkfs может быть получен передачей buildfs "пустой" внешней таблицы инф.узлов (т.е. с одним root каталогом). mkfs в пакете может и остаться -- но это будет уже совсем не тот mkfs, что сейчас -- скрипт `mkfs` в этом случае будет лишь вызывать buildfs с одной дополнительной опцией, которая скажет ему сгенерировать пустую внешнюю таблицу инф.узлов.

народ, а подскажите, как не перегружаясь в винду (и используя одну из массы XXX Recovery прог) восстановить потертое файло с флэшки (FAT16/32) ? Есть нативный софт под линукс?

Ну попробуй build_it + anysurrect из этого пакета.
Если что-то непонятно -- пиши.

спасибо, попробую на досуге.

А можно ли теоретически _програмно_ востановить дание с раздела унечтоженого 'shred -n 0 -z /dev/hda1'?

Думаю, такой задачи практически не стоит:
вы не найдёте данных уничтоженных 'shred -n 0 -z /dev/hda1', потому, что если надо уничтожить данные, то не будут ставить '-n 0' :-)

> Ну, нужно не одно письмо. Лучше чтобы был именно представитель проекта, сам понимающий все преимущества (ну и недостатки разумеется) anyfs-tools. Иначе это будет просто переводчик :-)

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

> Значит нужно тестирование и ещё раз тестирование...

Да, это и самому приятно, только утомительно. После частого и активного программирования хочется писать еще-еще (новые возможности), а не тестить...

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

А насколько оптимально build_* делает такую генерацию по сравнению с mkfs? И по идее, если ты хорошо знаешь код mkfs.* то тебе легче будет завоевать авторитет у авторов mkfs.*. Хотя mkfs.xfs вряд ли поддастся ;-) Там ведь постоянно что то добавляют в xfs...

> А можно ли теоретически _програмно_ востановить дание с раздела унечтоженого 'shred -n 0 -z /dev/hda1'?

Можно. Теоретически. Почитайте про MFM/RLL ;-) Шансы есть, но только если у вас будут полные данные на команды управления контроллером жесткого диска.

Хотя не все, наверняка. Хвосты только.

>И самое главное -- ebuild прилагается

Это как раз не самое главное..:-)

насчет копирования разделов - я не понял, чем это лучше tar?

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

> Подумай, сколько у тебя еще времени и интереса хватит на этот проект?
По-моему, интерес приходит во время разработки примерно как "аппетит во время еды" :-)
А со временем, конечно, да -- сложнее.

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

> А насколько оптимально build_* делает такую генерацию по сравнению с mkfs?
Если это столь важно, то можно оставить ровно в одном месте двойной код -- иначе buildfs будет побайтно пересчитывать свободное место, тогда как в mkfs это делается простой арифметикой.

> И по идее, если ты хорошо знаешь код mkfs.* то тебе легче будет завоевать авторитет у авторов mkfs.*.
:-) У меня наглости не хватит с моим английским приставать к разработчикам со столь серьёзной просьбой :-)

> насчет копирования разделов - я не понял, чем это лучше tar?
Прочти, пожалуйста:
http://anyfs-tools.sourceforge.net/ru/man8/anyconvertfs.8.html#lbAF
Всё по-русски!

> насчет восстановления - непонятно какие алгоритмы используются и какие результаты ожидаются.
восстановление не зависимое от файловой системы, производится исходя исключительно из знакомой структуры различных типов файлов.
Недостатком является -- не восстановление имён файлов и не распознавание фрагментированных файлов.
http://anyfs-tools.sourceforge.net/ru/man8/anysurrect.8

Но здешняя публика так ждёт ебилдов, что подчас кажется, что это главное ;-)

Респект!

Респект.

Будет время - попробую в LFS. Понравится - попробую "пропихнуть" в этот проект. (скорее всего в BLFS, но кто знает...)

Если не понравится -- обязательно пишите, что не понравилось ;-)

Как диссертацию защищу... То бишь где-то в январе после выхода из запоя :))

Удачной защиты!
И поберегите печень ;-)

Defrag бы еще... 8)

>> насчет копирования разделов - я не понял, чем это лучше tar?

>Прочти, пожалуйста: 
> http://anyfs-tools.sourceforge.net/ru/man8/anyconvertfs.8.html#lbAF 

ага, понял... только конвертировать получается... заменой tar или dump/restore оно никогда не станет.
соответственно странно ожидать включения этой функциональности в mkfs (хотя конечно идея красивая).

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

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

вот это интереснее...

Если боитесь фрагментации -- конвертируйте в XFS и xfs_fsr к вашим услугам.

> ага, понял... только конвертировать получается... заменой tar или dump/restore оно никогда не станет.
Для простого пользователя? Я не говорю об админе у которого _должен_ быть backup -- т.е. фактически для него dump уже сделан -- для перехода на другую ФС достаточно сделать restore.
А у простого пользователя редко находится место чтоб так запросто скопировать целый раздел.
А если это станет надёжным (а поддержка майнтейнерами ФС сильно увеличивают надёжность) -- то там уж и не совсем простые пользователи подтянуться..
Майнтейнерам же это может помочь привлечь новых пользователей. Потому, что попробовать новую ФС пользователю часто мешает только отсутствие надёжного и быстрого способа сконвертировать его текущую ФС.
А если ещё к этому добавить, что постоянное проведение build_it поможет сохранить данные даже если эта испробуемая ФС рухнет -- тут тем более может прибавиться пользователей у той же Reiser4 -- Гансу ведь нужны новые пользователи? Но кто осмелиться перевести свои важные данные без подстраховки, когда ФС ещё не считается особенно надёжной? build_it может стать именно той подстраховкой для пользователя!

Хорошая вешь.. Живой проэкт..

Мдэ, видно так и не сподобиться никто сделать дефраг под рейзер....

в xfs отсутствует фрагментация?

В XFS максимально позаботились о том, чтобы фрагментация не росла, и есть дефрагментатор (xfs_fsr).

А зачем? В Reiser'е так хорошо растёт фрагментация?

make[2]: Entering directory `/home/evg/download/make/anyfs-tools-0.84.5a/src/build_xfs' gcc -g3 -O3 -Wall -std=gnu99 -I../../include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DDEBUG -funsigned-char -fno-strict-aliasing -g -O2 -c maxtrres.c gcc -g3 -O3 -Wall -std=gnu99 -I../../include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DDEBUG -funsigned-char -fno-strict-aliasing -g -O2 -c build_xfs.c In file included from /usr/include/ext2fs/ext2fs.h:68, from ../../include/bitops.h:8, from build_xfs.c:34: /usr/include/ext2fs/ext2_types.h:18: error: conflicting types for '__s64' /usr/include/xfs/platform_defs.h:42: error: previous declaration of '__s64' was here /usr/include/ext2fs/ext2_types.h:19: error: conflicting types for '__u64' /usr/include/xfs/platform_defs.h:41: error: previous declaration of '__u64' was here build_xfs.c: In function 'write_extentlist': build_xfs.c:773: warning: format '%llu' expects type 'long long unsigned int', but argument 4 has type 'uint64_t' build_xfs.c:773: warning: format '%llu' expects type 'long long unsigned int', but argument 5 has type 'uint64_t' build_xfs.c:1043: warning: format '%llu' expects type 'long long unsigned int', but argument 4 has type 'uint64_t' build_xfs.c:1043: warning: format '%llu' expects type 'long long unsigned int', but argument 5 has type 'uint64_t' build_xfs.c: In function 'main': build_xfs.c:2971: warning: format '%llx' expects type 'long long unsigned int', but argument 3 has type 'uint64_t' build_xfs.c:3111: warning: format '%llu' expects type 'long long unsigned int', but argument 4 has type 'uint64_t' build_xfs.c:3111: warning: format '%llu' expects type 'long long unsigned int', but argument 4 has type 'uint64_t' build_xfs.c:3161: warning: format '%llu' expects type 'long long unsigned int', but argument 4 has type 'uint64_t' build_xfs.c:3161: warning: format '%llu' expects type 'long long unsigned int', but argument 4 has type 'uint64_t' build_xfs.c:3163: warning: format '%llu' expects type 'long long unsigned int', but argument 3 has type 'uint64_t' build_xfs.c:3163: warning: format '%llu' expects type 'long long unsigned int', but argument 3 has type 'uint64_t' build_xfs.c:3444: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness build_xfs.c:3771: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness build_xfs.c:3927: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness make[2]: *** [build_xfs.o] Ошибка 1 make[2]: Leaving directory `/home/evg/download/make/anyfs-tools-0.84.5a/src/build_xfs' make[1]: *** [build_xfs_util] Ошибка 2 make[1]: Leaving directory `/home/evg/download/make/anyfs-tools-0.84.5a/src' make: *** [progs] Ошибка 2

Fedora 5 (x86_64)

В новой версии 0.84.5b должно быть поправлено.
Проверь, пожалуйста.
Если соберётся, тоже пиши. Должен же я знать, если всё впорядке.
Пиши, пожалуйста, на e-mail.

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

> и всё потому что нет дефрага.
Нет, это потому, что кто-то не хочет переходить на XFS :-)

Хехехе, XFS не устраивает по ряду причин : огромное дерево каталогов + куча мелких файлов. Рейзер в такой конфигурации гораздо предпочтительней - быстрей пашет.

А если серьёзно - то отсутсвие дефрага сильно напрягает на всех файловых системах линукса. В идеале хотелось бы иметь демон неспешно наводящий порядок на смонтированных ФС.

Но похоже этим вопросом заниматься никто не хочет - а жаль. Вопрос достаточно актуальный и наболевший. Достаточно погуглить по этому поводу и тихо зарыдать 8).

> Хехехе, XFS не устраивает по ряду причин : огромное дерево каталогов + куча мелких файлов. Рейзер в такой конфигурации гораздо предпочтительней - быстрей пашет.

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

> В идеале хотелось бы иметь демон неспешно наводящий порядок на смонтированных ФС.
Вот, для XFS именно это существует.

А так это возможно только добавление в VFS ядра дополнительного API для дефрагментации, а там может какие-нить ФС и реализуют это API.
Но это же отнюдь не просто...

>>>а насчёт огромного дерева каталогов -- не думаю, что Би-деревья в XFS хуже чем в ReiserFS...

Проверено не раз - на большом дереве рейзер уделывает любую существующую на сей момент ФС.

>>>Но это же отнюдь не просто...

Дык! Было б просто - наверняка уже бы чего-то сваяли. Насчет API я хз - интересно можно ли заюзать мапинг файлов ? (так как это делает LILO)

На Fedora5 (x86_64) версия 0.84.5b собралась и успешно отработала на конвертировании ext3 в xfs.
Спасибо.

> Проверено не раз - на большом дереве рейзер уделывает любую существующую на сей момент ФС.

Возможно и так. Будем знать..

> Дык! Было б просто - наверняка уже бы чего-то сваяли. Насчет API я хз - интересно можно ли заюзать мапинг файлов ? (так как это делает LILO)

Мапинг файлов у меня у самого ровно также в build_it используется. Но так как API для обратного действия (ремапинга) не существует, то увы..

Вам спасибо большое за баг-репорт и использование утилиты.