Сайт | Скачать | Видео | Wiki

Автор Тема: dynfilefs : fs-in-file на fat,ntfs c динамическим увеличением размера  (Прочитано 9934 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн sfs

  • Администратор
  • Ветеран
  • *****
  • Сообщений: 33965
  • Репутация: +231/-0
  • Автор темы
    • PuppyRus-A
Dynamic size filesystem
Как известно , существует возможность установить FRUGAL linux даже на fat,ntfs (т.е. Windows разделы)
В этом случае сохранение изменений в каталог не возможно.
Возможно в файл с линуксовой fs внутри
Место в таком файле может закончиться и увеличить можно только созданием нового и копированием данных
Вот эту проблему и решает dynfilefs
Код
usage: ./dynfilefs [storage_file] [sizeMB] [mountpoint]

Mount filesystem to [mountpoint], provide a virtual file ./loop.fs
of size [sizeMB] so you can make a filesystem on it and mount it.
Store all changes made to loop.fs to [storage_file]

  [storage_file] - path to a file where all changes will be stored.
  [sizeMB]       - loop.fs will be sizeMB * 1024 * 1024 - 1 bytes long

Example usage:

  # ./dynfilefs /tmp/changes.dat 1024 /mnt
  # mke2fs -F /mnt/loop.fs
  # mount -o loop,sync /mnt/loop.fs /mnt

Имейте в виду, что файл [storage_file] имеет около 0,4% накладных расходов, поэтому, если вы
поместите данные [sizeMB] в loop.fs, тогда файл [storage_file] будет немного больше
чем указано [sizeMB]. Это важно, если вы сохраняете изменения на VFAT,
поскольку VFAT имеет ограничение на размер файла 4 ГБ, поэтому вы не можете хранить полные 4096 МБ данных
из-за накладных расходов. Для каждого 64 МБ данных требуется 256k + 8 байтов.
Проверил - работает. Т.е. при копировании в /mnt раздувается changes.dat. Примонтировать changes.dat или посмотреть внутренности - не знаю как (кроме стандартного метода)
Большой минус - при освобождении места - обратно не сдувается

Исходники
Статический файл (т.е. без зависимостей , 32 и 64 бит одновременно)

Реализован в https://www.linux-live.org/
Можно и в наши инитрд прикрутить....
Надо ли... На линуксовом разделе все равно удобнее. Отсутствие лин. разделов - в основном у новичков, которым dynfilefs будет сложно
« Последнее редактирование: 28 Декабрь 2017, 13:52:58 от sfs »

Оффлайн betcher

  • Ветеран
  • *****
  • Сообщений: 3019
  • Репутация: +35/-0
    • MagOS linux
Давно такие используем, проблема только в том, что файл умеет только расти. Попробуйте смонтировать, а потом несколько раз записать в него и удалить некоторое количество файлов. А затем удалить из него все и посмотреть размер самого file.img.
А что тут можно прикрутить к инитрд. Сделанный таким способом файл и так везде подключится.
Или я не о том?
http://www.magos-linux.ru/dwiki/doku.php?id=создание_динамически_расширяющегося_профиля
« Последнее редактирование: 28 Декабрь 2017, 14:13:49 от sfs »

Оффлайн sfs

  • Администратор
  • Ветеран
  • *****
  • Сообщений: 33965
  • Репутация: +231/-0
  • Автор темы
    • PuppyRus-A
Давно такие используем
Можно пример использования для добавления http://wiki.puppyrus.org/soft/uird

Сделанный таким способом файл и так везде подключится.
Т.е. если указать файл /mnt/loop.fs в качестве сохраненки и пути не изменились - все будет работать без правок инитрд?

Оффлайн betcher

  • Ветеран
  • *****
  • Сообщений: 3019
  • Репутация: +35/-0
    • MagOS linux
Да без изменений, если мы об одном и том же. Добавил ссылку в предвдущий пост.

Оффлайн sfs

  • Администратор
  • Ветеран
  • *****
  • Сообщений: 33965
  • Репутация: +231/-0
  • Автор темы
    • PuppyRus-A
Нет - dynfilefs -это другое
Цитата
создать динамический профиль определенного максимального размера, но который на диске занимает место равное реально занятому пространству
Т.е. достаточно ключа of=max_2G и все работает так же как dynfilefs ... ?
Тоже раздувается , но не сдувается...?
Работает при размещении на fat и ntfs?

Оффлайн betcher

  • Ветеран
  • *****
  • Сообщений: 3019
  • Репутация: +35/-0
    • MagOS linux

Оффлайн sfs

  • Администратор
  • Ветеран
  • *****
  • Сообщений: 33965
  • Репутация: +231/-0
  • Автор темы
    • PuppyRus-A
Тогда не понятно зачем было изобретать dynfilefs ....
Какой-то здесь подвох

Оффлайн Pro

  • Активный участник
  • Ветеран
  • ****
  • Сообщений: 10737
  • Репутация: +113/-2
В puppy файл сохранения можно было увеличивать
Я загружаю новые пакеты сюда: http://file.puppyrus.org/users/ а дальше можно найти самостоятельно.

Оффлайн sfs

  • Администратор
  • Ветеран
  • *****
  • Сообщений: 33965
  • Репутация: +231/-0
  • Автор темы
    • PuppyRus-A
Да, но вроде так:
увеличить можно только созданием нового и копированием данных

Оффлайн Pro

  • Активный участник
  • Ветеран
  • ****
  • Сообщений: 10737
  • Репутация: +113/-2
Да, но вроде так:
увеличить можно только созданием нового и копированием данных

я увеличивал через штатный gui, и не вдавался в подробности
Я загружаю новые пакеты сюда: http://file.puppyrus.org/users/ а дальше можно найти самостоятельно.

Оффлайн sfs

  • Администратор
  • Ветеран
  • *****
  • Сообщений: 33965
  • Репутация: +231/-0
  • Автор темы
    • PuppyRus-A
Были бы интересны как раз подробности

Оффлайн DdShurick

  • Это Риччи
  • Активный участник
  • Ветеран
  • ****
  • Сообщений: 8635
  • Репутация: +187/-2
  • Старый чайник
Были бы интересны как раз подробности
Для начала смотрим /usr/sbin/resizepfile.sh в PR. Это GUI, задача которого записать в файл pupsaveresize.txt на сколько увеличивать файл сохранения.
Код
echo -n "$KILOBIG" > /initrd${PUP_HOME}/pupsaveresize.txt
Далее файл pupsaveresize.txt всплывает в init из initrd.gz
Код
928:   if [ -f /mnt/dev_save/pupsaveresize.txt ];then #created by /usr/sbin/resizepfile.sh
929:    KILOBIG=`cat /mnt/dev_save/pupsaveresize.txt`
930:    rm -f /mnt/dev_save/pupsaveresize.txt
931:    echo > /dev/console
932:    echo -n "Увеличение $PUPSAVEFILE на $KILOBIG Kbytes, пожалуйста, ожидайте..." >/dev/console
933:    dd if=/dev/zero bs=1024 count=$KILOBIG >> /mnt/dev_save$PUPSAVEFILE
934:    sync
935:    e2fsck -y -f /mnt/dev_save$PUPSAVEFILE
936:    resize2fs -pf /mnt/dev_save$PUPSAVEFILE
937:    sync
938:    check_status 0
939:    echo -n "...продолжение загрузки $PUPSAVEFILE..." > /dev/console
940:   fi
Из строки 933 понятно, что необходимое количество нулей просто дописывается в конец файла сохранения с последующей проверкой файловой системы утилитами /sbin/e2fsck и /bin/resize2fs. Всё это делается через перезагрузку, короче - костыль.
 ИМХО. Гораздо продуктивнее сохранять пользовательские данные на примонтированном к /home разделе, а изменения в системе в sfs|xzm.
Моноблок Lenovo IdeaCentre c200 (Intel Atom D525, Intel GMA 3150, 2 Gb RAM) Richy64
Nettop Acer Aspire Revo R3610 (Atom N330, nVidia GeForce 9400, 3 Gb RAM) Richy64

Оффлайн sfs

  • Администратор
  • Ветеран
  • *****
  • Сообщений: 33965
  • Репутация: +231/-0
  • Автор темы
    • PuppyRus-A
ИМХО. Гораздо продуктивнее сохранять пользовательские данные на примонтированном к /home разделе, а изменения в системе в sfs|xzm.
Согласен. Причем достаточно просто вынести нужные папки (не конфиги и т.п.) из home симлинками (ln -s) на раздел с любой ФС

Оффлайн neobht

  • Ветеран
  • *****
  • Сообщений: 1031
  • Репутация: +15/-0
Эта штука называется sparse file. На ntfs можно. На fat32 -нет.

Оффлайн stea.61

  • Пользователь
  • **
  • Сообщений: 45
  • Репутация: +6/-0
Доброго всем дня!
Разрешите поприветствовать всех и поучаствовать в обсуждение вопроса - немного копал эту же тему. )
Тогда не понятно зачем было изобретать dynfilefs ....
Какой-то здесь подвох
Подвох есть.
1. Как уже заметил  neobht, трюк со sparse file прокатывает только на NTFS, на FAT файл, конечно, создается, но под него сразу выделяется место по заданному значению отсечения (seek=...) и динамическое свойство теряется.
2. Файловые менеджеры отображают такой файл по размеру отсечения - можно предположить проблемы с корректностью записи данных при недостатке места на носителе (не утверждаю, т.к. не проверял).
 Dynfilefs этих недостатков не имеет, поэтому в своей "RUNTU Linux Compact" я использовал dynfilefs.
У него тоже есть своя проблемка:  довольно небольшая скорость записи в файл - у меня в тестах получилось в среднем порядка 5 MB/s.
Замедление реакции системы заметно невооруженным глазом.
Для своих целей сочинил более интересный (на мой взляд) вариант динамического файла "сохраненки" - для системы на NTFS использую sparse file, на FAT - стандартный файл VDI формата, который монтирую qemu-nbd .
В тестах наблюдал среднюю  скорость записи в sparce file  порядка 35 MB/s, в VDI - порядка 15 MB/s, в VHDX - порядка 25 MB/s (тестировал практически все форматы вирт-дисков, поддерживаемые qemu-nbd - VDI по совокупности свойств показался самым подходящим).
В таком варианте замедления реакции системы визуально практически не наблюдаю.



« Последнее редактирование: 29 Декабрь 2017, 20:20:35 от stea.61 »