Portage tree in squashfs

В sys-kernel/geek-sources-3.7.6 внезапно вот эта и не менее внезапно вот оттуда git://aufs.git.sourceforge.net/gitroot/aufs/aufs3-standalone.git и никаких sys-fs/aufs{2/3} и sys-fs/aufs-util тебе вообще не нужно.

Благодарю.

aufs-util ннада есди хочется самому паковать файлы т.к. в них mksquashfs и unsquashfs

aufs-util ннада есди хочется самому паковать файлы т.к. в них mksquashfs и unsquashfs

Что?

 equery b mksquashfs
 * Searching for mksquashfs ... 
sys-fs/squashfs-tools-4.2_p20121216 (/usr/bin/mksquashfs)

init_6, проблема вылезла.

Сделал всё по этой инструкции (лишь поменял кое-что, но это несущественно). Запустил скрипт, он создал образ squashfs, всё ок, но в конце вылезло вот что:

 * Clearing /src/portage
 * SQFS-PORTAGE: Mounting read-only squashfs image ...
 * Mounting read-write with aufs ...
 *   mounted in tmpfs (RAM)                                                            [ ok ]
 * Mounting read-write with aufs ...
mount: wrong fs type, bad option, bad superblock on aufs,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail or so

dmesg:

nona / # dmesg | tail
[95377.812452] ... kick the bucket
[95377.812455] ... kick the bucket
[95377.812711] lz4: pg_out 33 > 32 nr_dest, nr_out 33; len 131072 out_len 131229 hdr 8, ino 427578
[95377.812712] ... kick the bucket
[95377.813541] lz4: pg_out 33 > 32 nr_dest, nr_out 33; len 131072 out_len 131449 hdr 8, ino 427578
[95377.813542] ... kick the bucket
[95377.815802] lz4: pg_out 33 > 32 nr_dest, nr_out 33; len 131072 out_len 131467 hdr 8, ino 427578
[95377.815804] ... kick the bucket
[95383.194319] aufs test_add:264:mount[26556]: uid/gid/perm /src/portage 250/250/0755, 250/250/0750
[95383.198705] aufs test_add:234:mount[26562]: unsupported filesystem, /src/portage (aufs)

М.б. у меня в ядре aufs с неправильными опциями собрана?

nona / # zgrep AUFS /proc/config.gz 
CONFIG_AUFS_FS=m
CONFIG_AUFS_BRANCH_MAX_127=y
# CONFIG_AUFS_BRANCH_MAX_511 is not set
# CONFIG_AUFS_BRANCH_MAX_1023 is not set
# CONFIG_AUFS_BRANCH_MAX_32767 is not set
CONFIG_AUFS_SBILIST=y
# CONFIG_AUFS_HNOTIFY is not set
# CONFIG_AUFS_EXPORT is not set
CONFIG_AUFS_RDU=y
CONFIG_AUFS_PROC_MAP=y
CONFIG_AUFS_SP_IATTR=y
CONFIG_AUFS_SHWH=y
# CONFIG_AUFS_BR_RAMFS is not set
CONFIG_AUFS_BR_FUSE=y
CONFIG_AUFS_POLL=y
CONFIG_AUFS_BR_HFSPLUS=y
CONFIG_AUFS_BDEV_LOOP=y
# CONFIG_AUFS_DEBUG is not set

См параметры mount после выхлопа «Mounting read-write with aufs»

mount -t aufs -o nodev,noexec,br=$PORTAGE_RW=rw:$PORTDIR=ro aufs $PORTDIR

Так и примонтировано:

nona / # mount | grep aufs
aufs on /src/portage type aufs (rw,nodev,noexec,br=/dev/shm/.portage-rw=rw:/src/portage=ro)

Не пойму, на что он жалуется тогда?

скваши там где настроено посоздавались? дальше start stop sync/restart нормально?

Прогнал stop/start, всё ок, этого сообщения больше нет.

А ты оверлеи в squashfs не запихивал?

А ты оверлеи в squashfs не запихивал?

У меня в скваше и портежи и оверлеи.

Я вот думаю ещё базу установленных пакетов (/var/db/*) и кэш (/var/cache/edb) туда запихать. Чтобы всё относящееся к пакетному менеджеру было в tmpfs. Теоретически, должно хорошо поднять скорость обсчёта.

Я вот думаю ещё базу установленных пакетов (/var/db/*) и кэш (/var/cache/edb) туда запихать.

Плохая идея.

А вот /usr/src/linux вполне!

Плохая идея

Это почему?

А вот /usr/src/linux вполне!

Не, over 800 метров памяти под это отдавать жаба душит.

Это почему?

Эмитируем екстремальную ситуацию. У тебя ВНЕЗАПНО нету aufs и squashfs. В случае портежей и оверлеев ну и не пофиг ли? Главное чтобы сеть была… А если у тебя там /var/db/* и /var/cache/edb то это полный пипец!

А вот /usr/src/linux вполне!

а вот это зачем?

У тебя ВНЕЗАПНО нету aufs и squashfs

А если у меня внезапно нет корневой ФС?

А если у меня внезапно нет корневой ФС?

По моему более вероятен вариант корневая фс ок а aufs либо squashfs поломался.

И еще более вероятен скваш плохо записался при последней синхрониации. В таком случае опять же если ты чего то наустанавливал а /var/db/* и /var/cache/edb были в неправильнозаписанном скваше… Все у тебя будет Ок!

По моему более вероятен вариант корневая фс ок а aufs либо squashfs поломался.

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

И еще более вероятен скваш плохо записался при последней синхрониации

У тебя такое было?

У тебя такое было?

Да. Иначе я бы и не говорил об этом.

Ясно. Но можно же поправить скрипт чтобы база портежа наряду с упаковкой в squashfs бэкапилась в простой архив.

Ясно. Но можно же поправить скрипт чтобы база портежа наряду с упаковкой в squashfs бэкапилась в простой архив.

Ну играйся. Просто как на мой взгляд так portage, layman, /usr/src/linux да смысл есть.

На мой взгляд засовывать дерево в tmpfs, а базу и кэш оставлять на диске - половинчатое решение. А /usr/src в tmpfs вообще нафиг не нужно.

По сабжу есть еще пот такая херь - squash_dir выглядит интересно но лично я её не тестировал и юзаю тот что по wiki.

На мой взгляд засовывать дерево в tmpfs, а базу и кэш оставлять на диске - половинчатое решение. А /usr/src в tmpfs вообще нафиг не нужно.

Читай как оно все работает. Емнип пока скваш на ro там ничего из озу не трогает. Трогать начинает aufs после того как внесены изменения на фс.

Я бы базу и кеш все же не трогал.

Что-то я ускорения вообще не заметил. emerge -uDNpv @world при 160-ти обновляемых пакетах выполняется за те же полторы минуты, что и раньше.

Слушай, а зачем вся эта заморока с squashfs, каскадным монтированием aufs и проч.? Не легче ли было упаковать дерево в банальный архив xz/lzo/gzip и написать скрипт, который бы распаковывал этот архив в tmpfs при загрузке и упаковывал обратно при выключении?

Слушай, а зачем вся эта заморока с squashfs, каскадным монтированием aufs и проч.? Не легче ли было упаковать дерево в банальный архив xz/lzo/gzip и написать скрипт, который бы распаковывал этот архив в tmpfs при загрузке и упаковывал обратно при выключении?

Пиши. Только учти что в случае squashfs+aufs реально память нужна только при изменении и проц только при упаковке.

Айноды экономит даже со стандартной gz.

в случае squashfs+aufs реально память нужна только при изменении

Не понял, это как?

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

Дерево + оверлеи - секунд 5 максимум.

Т.е. получается, что squashfs просто монтируется как образ, без перенесения содержимого в tmpfs? Ну тогда нет ничего удивительного в отсутствии ускорения обсчёта зависимостей, хех.

В принципе, на дерево с оверлеями уйдёт максимум метров 500 оперативки. Некритично.

В принципе, на дерево с оверлеями уйдёт максимум метров 500 оперативки

Кстати, можно попробовать zram заюзать.

Не понял, это как?

Это возьми и посмотри free затем запусти emerge --sync layman -S посмотри free еще раз затем пересоздай скваш /etc/init.d/* restart и снова посмотри free

Ну тогда нет ничего удивительного в отсутствии ускорения обсчёта зависимостей, хех.

Что что? SquashFs Comparisons

А если всё переместить в zram, вместо полутора минут emerge -uDNvp @world выполняется за:

...
Total: 174 packages (150 upgrades, 6 downgrades, 8 new, 1 in new slot, 9 reinstalls), Size of downloads: 436,011 kB

The following USE changes are necessary to proceed:
 (see "package.use" in the portage(5) man page for more details)
#required by app-office/akonadi-server-1.9.0, required by kde-base/kdepim-runtime-4.10.0, required by kde-base/kdepim-common-libs-4.10.0, required by kde-base/kmail-4.10.0, required by @selected, required by @world (argument)
>=x11-libs/qt-sql-4.8.4 mysql

real    0m18.759s
user    0m18.519s
sys     0m0.142s