LINUX.ORG.RU

Программеры есть? А можете на халяву реализовать небольшой проект? Думаю можно даже на скриптовом языке. Идея: «Дерево дырок»

 , ,


4

8

Идея: Компактный индекс съёмного носителя.
Реализация: Делать дырявую копию дерева каталогов/файлов - сохраняя владельцев/время/права доступа. Затем делать .sq из этого дерева и при желании иметь возможность подмонтировать и посмотреть это дерево.
В течение 25+ лет работы ИТшником - набралось масса барахла на съёмных носителях. Есть куча флешек, куча винтов... Надо это как то индексировать.

Изначально спрашивал в Админ форуме. Думал это уже реализовано - но никто не подсказал пруфлинков. Лишь некий driano32 в Ветке: Создать ISO со служебной информацией из дерева каталогов. Чем? дал простейший скрипт генерящий дерево дырок. Но работает оно очень долго....
Мог бы кто то реализовать эту идею в одной программе на скриптовом языке? У меня в экспериментах это стало выглядеть
tree-hole.sh:

#!/bin/sh
#Упаковка Фантома каталога
timestamp=`date +%y%m%d-%H%M%S`
echo $timestamp
if [ "$1" = "" ]; then
echo "Запускать надо так: $0 <Каталог> <Архив/дырка>"
else
echo "Аргументы = $1 $2"
fi

DIR_PREFIX="/opt/pub/_T3T/Data/tree-$2"
SOURCE=$1
TARGET=$2
CUR_DIR=`pwd`
if [ -d "$DIR_PREFIX" ]; then
    echo $DIR_PREFIX" is already created, skipping."
  else
    mkdir "$DIR_PREFIX"
    chmod -fR 755 "$DIR_PREFIX"
fi
echo '#/bin/sh' > "$DIR_PREFIX/mod_script"
echo 'DIR_PREFIX='$DIR_PREFIX >> "$DIR_PREFIX/mod_script"
echo 'if [ -f "$1" ]; then' >> "$DIR_PREFIX/mod_script"
echo '  attrib=`stat -c %a -- "$1"`' >> "$DIR_PREFIX/mod_script"
echo '  owner=`stat -c %U -- "$1"`' >> "$DIR_PREFIX/mod_script"
echo '  group=`stat -c %G -- "$1"`' >> "$DIR_PREFIX/mod_script"
echo '  size=`stat -c %s -- "$1"`' >> "$DIR_PREFIX/mod_script"
echo 'dd if=/dev/null of="$DIR_PREFIX/$1" bs=1 seek=$size && chown $owner:$group -- "$DIR_PREFIX/$1" && chmod $attrib -- "$DIR_PREFIX/$1"' >> "$DIR_PREFIX/mod_script"
echo 'fi' >> "$DIR_PREFIX/mod_script"
find $SOURCE -type d -exec mkdir "$DIR_PREFIX"/"{}" \;
find $SOURCE -type f -exec sh "$DIR_PREFIX/mod_script" "{}" \;
rm -f $DIR_PREFIX/mod_script
#genisoimage -allow-leading-dots -allow-lowercase -allow-multidot -iso-level 4 -l -o `date +%s`.iso "$DIR_PREFIX"
echo Start: $timestamp|tee -a $2.time
timemid=`date +%y%m%d-%H%M%S`
echo Mid: $timemid|tee -a $2.time
mksquashfs "$DIR_PREFIX/$1" $2.sq
timeend=`date +%y%m%d-%H%M%S`.
echo End: $timeend|tee -a $2.time
###Fucking Sheet rm -rf $DIR_PREFIX


Небольшой каталог в 32Gb оно за 6 минут ужимает в 69килобайтный .sq,а вот 1.7Тб каталог крутит со вчерашнего вечера...

Может кто поддержит и реализует эту идею? Тогда у общественности появится механизм индексации носителей

Этот механизм можно потом и развить - скажем добавляя в дерево md5 суммы файлов исходного каталога и получить механизм верификации изменений в ФС. Можно так и хранить долгоживущую дырку и инкрементально апдейтить хэши в ней.

Вот как то так...

P.S. Пробовал разные каталогизаторы (не помню всех имён), но ни один из них (даже cdcat из официального Debian репозитария) не смог переварить дерево 1.7Тб и кажется даже дерево 500Гб.
Просто работал, работал, работал и вдруг умирал...

★★

Ответ на: комментарий от Deleted

Могу попробовать. Обязательно на скриптовом языке?

Лучше на скриптовом. Оно прозрачно и каждый сможет допилить и не надо пересобирать...

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

Ок, тогда на питоне и посмотрим как с производительностью будет.

Замечательно! Я как раз вернулся чтобы означить интерес в реализации на Питоне.

n0mad ★★ ()
Последнее исправление: n0mad (всего исправлений: 1)

А какие типичные объемы этих съемных носителей?
Если это флопики по полтора мегабайта или меньше, по-моему, проще вылить всё их содержимое в единую ФС целиком и иметь 100% данных без вот этих всех костылей с велосипедами.
Заодно и профильтровать всё это барахло на доступность-наличие-отсутствие данных.
Всего делов-то - с десяток другой терабайт. Зато всё уже под рукой вместе с данными.

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

А какие типичные объемы этих съемных носителей?

Какие флопики? Скажем стопка винтов по 80Гб, 500Гб, 1Тб, 2тб, 3тб... На вскидку у меня штук 20 винтов есть... В онлайне на компе сейчас (3+3+1:Внутри)+(3+2+1:USB)=13тб. Имея каталоги - всегда их можно носить с собой на съёмном hdd и при потребности порыться в них... (В голове многое не умещается). Иногда вспоминаешь что то нужное - а откуда доставать?
Надо найти....
Тут нас правительство бомжами сделало (Гугль:Ударная 35) в процессе родилась куча медиафайлов судов, выселений, речей членов правительства валяющихся в разных местах... очередной бэкап потребовал реорганизации места и всё перетасовалось...
И когда понадобится - надо оперативно найти.
И сохранить в разных местах...
А то придут какие нибудь очередные члены с конфискацией...
А то эти члены обещают и угрожают а потом от своих слов отказываются...
Вот как то так...

n0mad ★★ ()
Последнее исправление: n0mad (всего исправлений: 3)
Ответ на: комментарий от n0mad

Получилось вот так: https://github.com/im-0/fsholetree

При «запаковке» /usr/lib на моей системе отрабатывает за 14 секунд против 481 секунды оригинального скрипта на баше.

Позже попробую на расте переписать 8).

Deleted ()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от LINUX-ORG-RU

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

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

увидеть ассемблерный листинг) Ага, если постараться то можно =)

Прозрачнее, ибо видно что и как сделано, а не просто что =) Ну да ладно это я просто бубню

LINUX-ORG-RU ★★ ()
Ответ на: комментарий от Deleted

Не лучше ли будет сделать файловую систему на FUSE? Тогда не придётся делать новое дерево, можно будет в read() просто возвращать нули. Смонтировал, сквошнул, размонтировал.

Как-то так: https://gist.github.com/i-rinat/18081f0f325560fab0a6668c0fc4e0df. Я не осилил сделать в опциях {sourcedir} {targetdir}, не поломав остальные опции — там какая-то непонятная мне магия обработки опций fuse. Так что sourcedir захардкожено в /usr.

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

Запихни все харды в стойку и повесь личное облако

А кто профинансирует?

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

Не лучше ли будет сделать файловую систему на FUSE? Тогда не придётся делать новое дерево, можно будет в read() просто возвращать нули. Смонтировал, сквошнул, размонтировал.

Интересная идея. Только тут есть одна проблема: у меня уже реализована возможность сохранения в том числе и файлов устройств и SUID-бита. Сейчас для самой утилиты сохранения это не требует рута, достаточно только прав на чтение, так как процесс, создающий «дерево дырок», как и mksquashfs, запускаются из под fakeroot. Fuse для этого придётся пускать под рутом либо, возможно, с какими-то capabilities. Не знаю, правда, насколько реально нужна эта фича.

Кстати, обнаружил ещё одну интересную особенность: работа вот этого всего с разреженными файлами. SquashFS поддерживает их, но утилита mksquashfs детектит их максимально неэффективным способом: поиском последовательностей нулей. В genisoimage каких-либо следов реализации поддержки разреженных файлов я вообще не нашёл, хотя rock ridge по идее их поддерживает. Возможно смотрел невнимательно.

Fuse, кстати, поддерживает SEEK_HOLE/SEEK_DATA в новых ядрах. А ещё SEEK_HOLE/SEEK_DATA может использовать для поиска дырок GNU tar. Но tar-архивы нельзя просто так взять и примонтировать =(. Вроде, правильно (==быстро) читать разреженые файлы можно ещё с помощью FIEMAP, но следов его использования в тулзах я тоже не нашёл, как и инфы про поддержку в FUSE в каком-нибудь виде.

Подозреваю, что проблема автора темы с большими объёмами данных ещё и в этом. Чтобы mksquashfs упаковал терабайт «дырок», ему придётся прочитать терабайт нулей. IO там не будет, но нагрузка на проц останется.

Deleted ()

Реализация: Делать дырявую копию дерева каталогов/файлов - сохраняя владельцев/время/права доступа. Затем делать .sq из этого дерева и при желании иметь возможность подмонтировать и посмотреть это дерево.

А смысл? Юзать ls,find,... ? Чем это лучше SELECT ... из базы данных?

futurama ★★★★★ ()

В течение 25+ лет работы ИТшником - набралось масса барахла на съёмных носителях. Есть куча флешек, куча винтов... Надо это выкинуть нахрен.

Лучшая программа - та, которую не пришлось писать :)

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

А смысл? Юзать ls,find,… ? Чем это лучше SELECT … из базы данных?

Это лучше там, что не требует дополнительного софта и использования незнакомых инструментов (SQL).

Лично мне вообще идея создания слепка всех метаданных файловой системы показалась интересной. Хотя я и не смог придумать для чего я сам бы мог этим воспользоваться. Разве что дописать утилиту для проверки целостности системы на основе этого…

Deleted ()
Ответ на: комментарий от futurama

ls -lR и grep, для тех кому лень освоить хотя бы на примитивном уровне SELECT

З.Ы. sqlite3 доступен везде.

Я не понял при чём тут ls и grep и как их использовать к SQLной базе данных. Идея сабжа как раз в том, чтобы можно было искать нужное при помощи ls, find и прочих стандартных утилит для работы с обычной файловой системой, при этом без необходимости хранить сами данные (они могут лежать в шкафу на куче жёстких дисков).

Deleted ()

Вброшу, так как не разбираюсь во вбрасываемом.
А нельзя ли для этого как-то настроить различные реализации locate/updatedb (gnu-findutils, mlocate и др.)?

anonymous ()
Ответ на: комментарий от Deleted

Тут недавно на форуме обсуждались патчи к mksquashfs, позволяющие генерировать его из tar-файла: Bounty: добавить в mksquashfs поддержку чтения из tar напрямую (docker -> squash)

Там уже есть реализация. Думаю, можно её за основу взять, и тогда получится вообще избежать возни со sparse-файлами.

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

Там уже есть реализация. Думаю, можно её за основу взять, и тогда получится вообще избежать возни со sparse-файлами.

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

На самом деле я думал добавить SEEK_HOLE/SEEK_DATA в squashfs-tools и попробовать отправить патч в апстрим. Не думаю что это мегасложно.

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

А эта реализация понимает sparse-файлы внутри tar-архивов?

Без понятия. Вообще лучше бы там выбросить tar-файлы как промежуточный элемент. Но это надо вникать в код, кодить, а лень.

На самом деле я думал добавить SEEK_HOLE/SEEK_DATA в squashfs-tools и попробовать отправить патч в апстрим. Не думаю что это мегасложно.

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

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

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

У mksquashfs уже есть опция -no-sparse, можно к ней привязать.

Deleted ()
Ответ на: комментарий от anonymous

У нас уже есть молоток - все будет гвоздями!

Вообще, кстати, да. Squashfs всё равно придётся монтировать, либо через ядерный драйвер, либо через FUSE. Раз монтировать, почему бы сразу не сделать на FUSE файловую систему, которая берёт метаданные из, скажем, sqlite3 базы данных? А данные в базу пихать отдельной утилитой.

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

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

Получилось вот так: https://github.com/im-0/fsholetree

Респект и УВАЖУХА!
Оперативно и работает. Я ещё не совсем понимаю матчасть - но оригинальный скрипт 2Тб диск молотит уже 3 день... К тому же там вроде в коде есть установка владельцев/времени/аттрибутов но по факту получается дерево дырок с временем запуска.
Твой сткрпт делает всё быстрее и точнее. Тут смотрю ниже начался спам про оптимизацию (я его пока не осилил) - но меня вполне устраивает что 350Gb данных ужалось в 1.6Mb .sq Сейчас запустил на:
B3T/pub 2,7T 2,7T 414M 100% /opt/pub.BKP
(Бэкап раздел на внешнем 3T HDD)
Вроде в скрипте веду время старта и завершения. Посмотрю на результат. Комп правда достаточно загружен файрфоксами...
top - 14:19:19 up 5 days, 7:32, 1 user, load average: 8,10, 7,94, 6,85
да и параллельно тот башевский скрипт молотит...

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

Как идея - overlayfs, unionfs или что-то подобное. В ro-слой индексируемый диск, в рабочий rw-слой - индекс. Прикоснуться ко всем, можно расширенные атрибуты установить. Потом можно мотировать вместе или без диска, и работать как с обычной фс. Это только идея, думаю, кому надо видит, что где не так в этой идее и как это можно исправить.

anonymous ()
Ответ на: комментарий от futurama

А смысл? Юзать ls,find,... ? Чем это лучше SELECT ... из базы данных?

Тем что для использование SELECT надо быть програмером а работа с моей идеей это универсальное решение.
В перспективе ни кто не мешает добавить некий функционал к дыркам.
Скажем md5 исходного дерева. Формат этой базы более универсален для сторонних утилит.
Для них это просто дерево в файловой системе.
Программеру конечно удобнее из своей базы выбрать самому то что хочет - но тут надо выходить на другой уровень абстракции.
Сначала сделать инструмент который будет читать деревья и складывать в базу SQL/sqliteА, а потом инструмент для выборки из этой базы.
Будет конечно быстрее - но для запуска надо инструментарий. В моём варианте mksquashfs уже думаю в каждом дистрибе есть.

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

ls -lR > file1

и

grep TEMPL file1

это для тех кто хочет привычные инструменты и не может освоить SQL

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

Я ещё не совсем понимаю матчасть

Этой фразой я имел в виду что не знаю как и куда разметить каталог fsholetree так чтобы запускать с минимальной командной строкой.
Пока я его кладу в тот каталог из которого вызываю и зову так как в ридми у автора: python -m fsholetree.cli

Подскажите - куда его поместить и как вызывать правильно?

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

осовоить find, awk, ls, ... не легче и не сложнее, чем SELECT на простом уровне, где основной упор будет на условии выбора WHERE

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

Ну пусть тебе напишут fuse интерфейс к базе данных, если ты так прикипел к ls, find

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

Тем что для использование SELECT надо быть програмером

за 25+ лет мог бы и осилить. придумал себе и другим проблему на ровном месте. а всё почему? а всё потому, что не владеешь инструментами, которые даёт тебе ос. да даже с grep/awk и обычным текстовым индексом это можно сделать. а ну да, ты же в них тоже не умеешь.

anonymous ()
Ответ на: комментарий от Deleted

Получилось вот так: https://github.com/im-0/fsholetree

задрот :) (в хорошем смысле слова).

очень аккуратно написано. приятно посмотреть.

c fakeroot'ом, как мне кажется, зря заморочился. если нельзя прочитать содержимое каталога, то всё равно придётся запускать от рута ведь.

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

Вообще, кстати, да. Squashfs всё равно придётся монтировать, либо через ядерный драйвер, либо через FUSE. Раз монтировать, почему бы сразу не сделать на FUSE файловую систему, которая берёт метаданные из, скажем, sqlite3 базы данных? А данные в базу пихать отдельной утилитой.

Стандартные форматы (squashfs, iso9660, tar) хороши тем, что в любом дистре линукса общего назначения они поддерживаются из коробки.

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

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

Deleted ()
Ответ на: комментарий от n0mad

Я ещё не совсем понимаю матчасть - но оригинальный скрипт 2Тб диск молотит уже 3 день…

А что именно занимает больше всего времени: создание дырок или финальный запуск mksquashfs? Если mksquashfs, то это как раз проблема с отсутствием в mksquashfs полноценного «детектора» разреженных файлов.

Deleted ()
Ответ на: комментарий от n0mad

Подскажите - куда его поместить и как вызывать правильно?

Правильно - опакетить под твой дистрибутив.

Но можно и вручную поставить:

  • Скопировать fsholetree (не все склонированные исходники, а именно директорию внутри) в /usr/lib/python2.7/site-packages/.
  • Создать файл /usr/local/bin/fsholetree с примерно таким содержимым:
#!/usr/bin/env python2
import fsholetree.cli as cli

cli.main()
  • chmod a+x /usr/local/bin/fsholetree
Deleted ()
Ответ на: комментарий от anonymous

да даже с grep/awk и обычным текстовым индексом это можно сделать.

С grep/awk и текстовым индексом поиск по, например, одновременно имени файла, границам размеров и границам времени создания получится сложнее, чем с БД и SQL запросом. А find позволяет сделать это довольно просто.

Deleted ()
Ответ на: комментарий от loz

Это из анекдота, где Буратино пошёл на Поле не с ворами, а с сутенёрами.

anonymous ()
Ответ на: комментарий от loz

дерево дырок

Расскажите что такое, это устоявшийся термин или как?

Нет. Но слово «hole» в контексте разреженных файлов вполне себе используется, см. SEEK_HOLE.

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

А что именно занимает больше всего времени: создание дырок или финальный запуск mksquashfs? Если mksquashfs, то это как раз проблема с отсутствием в mksquashfs полноценного «детектора» разреженных файлов.

Создание дырок. В итоге скрипт был остановлен на сообщениях типа: не найден файл ;№№;«№»№" до mksquashfs он не дошел.

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

Скопировать fsholetree (не все склонированные исходники, а именно директорию внутри) в /usr/lib/python2.7/site-packages/.

Хм... У меня в Debian Stretch есть:
/usr/lib/python2.7
/usr/lib/python3
/usr/lib/python3.5
Ни в одном из них нет site-packages - его создать? В каком из?

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

да даже с grep/awk и обычным текстовым индексом это можно сделать.

С grep/awk и текстовым индексом поиск по, например, одновременно имени файла, границам размеров и границам времени создания получится сложнее, чем с БД и SQL запросом. А find позволяет сделать это довольно просто.

Икстатида... ls -lR одного из моих накопителей состоит из 16057459 строки и занимает 1050M или 50M Упакованный bzip2.
К сожалению .sq этого каталога получить не удалось. Буду общаться с автором для дебага.

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

Да, fallocate именно этом и занимается (среди прочего). У меня даже есть такой скрипт, какая-либо польза совершенно отсутствует, лучше скопировать в разреженный файл через cp, чтобы избежать фрагментации.

linuxnewbie ()

25+ лет работы ИТшником

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

Всё давно уже украдено до нас и также давно забыто.

А как то, быстрый гуглёж выдал:

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

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

Ни в одном из них нет site-packages - его создать? В каком из?

А есть dist-packages? В дебиане кажется так называется.

Вообще нужно положить в директорию, которая есть в выводе

#!/usr/bin/env python2
import sys

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