Bug 27786

Мне на беглый взгляд не очень нравится патч, предложенный в #27407. Я бы не стал его прикладывать как есть.

(В ответ на комментарий №1)
> Мне на беглый взгляд не очень нравится патч, предложенный в #27407. Я бы не
> стал его прикладывать как есть.

Это proof of concept. Напускать unsquashfs на уже смонтированный в /.ro образ избыточно и кушает память.

(In reply to comment #1)
> Мне на беглый взгляд не очень нравится патч, предложенный в #27407.
А чем?

2sem: в преддверии регулярной публикации образов pre-p7 эта бага становится актуальной. Есть идеи?

(В ответ на комментарий №4)
> 2sem: в преддверии регулярной публикации образов pre-p7 эта бага становится
> актуальной. Есть идеи?

2mike, boyarsh, sem: ping
Мы собираем в том числе легкие live-образы, которые работают на <=256Mb, а установить их из Live не можем. Не уверен, что нужно обязательно предупреждать при ручной разбивке, достаточно замечания в подсказке. Но вот почему бы не увеличить swap?

Да, я в конце прошлой недели помнил эту багу, работая над livecd-install.

Делать ещё раз unsquashfs действительно кажется избыточным; мало того, на весьма быстрых CPU при 512M RAM в виртуальной машине нагрузка на процессор при разливке составляет что-то около 20%, т.е. образ заливается в несколько раз дольше, чем мог бы (при этом ISO лежит на довольно быстром диске, а sda -- на tmpfs; судя по "лампочкам", в них совсем не упираемся).

Но нужно не потерять работоспособность progress bar.

Created attachment 5681 [details]
патч с плавным progress bar

(В ответ на комментарий №6)
> Но нужно не потерять работоспособность progress bar.

Пример в патче.

Created attachment 5682 [details]
патч с плавным progress bar

Ночью промахнулся, bug 27407 comment 10 лучше было сюда.

vx8400@ предложил адаптивный алгоритм расчёта процента выполнения с внесением поправки "на лету", но если ориентироваться на размер, а не иноды -- оптимальнее выглядит его же вчерашнее предложение выполнить оценку размера тарбола с live-системой заранее при сборке stage2, когда у нас заведомо достаточно мощностей и памяти, да и кэш горячий; а трогать лишний раз болванку или флэшку всё-таки накладно.

Подумаю над этим и постараюсь сделать ещё один подход после более неприятных блокеров bug #27685.

PS: потребление памяти при установке regular-icewm (i586) было около 93M.

(В ответ на комментарий №9)
> PS: потребление памяти при установке regular-icewm (i586) было около 93M.

Поясните: при установке с каким-либо из обсуждавшихся тут изменений в установщике live?

(In reply to comment #10)
> > PS: потребление памяти при установке regular-icewm (i586) было около 93M.
> Поясните: при установке с каким-либо из обсуждавшихся тут изменений в
> установщике live?
Именно.  Варианты с tar и cp особо не отличались.  Своп не задействовался вовсе (VM с 512M RAM, на 256M формально проверить не успевал, но по free и так было понятно, что должно влезть).

(В ответ на комментарий №11)
> (In reply to comment #10)
> > > PS: потребление памяти при установке regular-icewm (i586) было около 93M.
> > Поясните: при установке с каким-либо из обсуждавшихся тут изменений в
> > установщике live?
> Именно.  Варианты с tar и cp особо не отличались.  Своп не задействовался вовсе
> (VM с 512M RAM, на 256M формально проверить не успевал, но по free и так было
> понятно, что должно влезть).

Тогда, если не будет возражений sem@, нужно собирать с этим изменением, пусть пользователи тестируют.

Оно ещё не готово, т.е. как минимум 205% можно получить запросто. :)

(В ответ на комментарий №13)
> Оно ещё не готово, т.е. как минимум 205% можно получить запросто. :)

Это шашечки. Пусть они и важны, но надо бы начать проверять как оно едет.
Впрочем, снизить до 140% было бы неплохо.

До 102% в случае regular-icewm снизили, а вот дальше -- или усложнение рантайма с адаптивной оценкой расхождения (уже разработанное и предложенное vx8400@), или подготовка точного размера заранее, или мухлёж типа реализованного в текущем варианте: http://git.altlinux.org/gears/a/alterator-livecd.git?p=alterator-livecd.git;a=blob;f=alterator-livecd/backend3/livecd-install;h=d93ce39b65d369740afcab712a31d97e32087360;hb=HEAD#l133

(В ответ на комментарий №15)
> До 102% в случае regular-icewm снизили, а вот дальше -- или усложнение рантайма
> с адаптивной оценкой расхождения (уже разработанное и предложенное vx8400@),
> или подготовка точного размера заранее, или мухлёж типа реализованного в
> текущем варианте:
> http://git.altlinux.org/gears/a/alterator-livecd.git?p=alterator-livecd.git;a=blob;f=alterator-livecd/backend3/livecd-install;h=d93ce39b65d369740afcab712a31d97e32087360;hb=HEAD#l133

Небольшой мухлеж допустим. :-)

Created attachment 5686 [details]
> ... усложнение рантайма с адаптивной оценкой расхождения

(В ответ на комментарий №16)
>  усложнение рантайма с адаптивной оценкой расхождения:

А есть смысл сохранять старый вариант с unsquashfs? Я бы его выкинул совсем и рассчитывал на то, что у нас всегда смонтирован образ в /.ro.

> > Оно ещё не готово, т.е. как минимум 205% можно получить запросто. :)
> 
> Это шашечки. Пусть они и важны, но надо бы начать проверять как оно едет.
> Впрочем, снизить до 140% было бы неплохо.

Вся сложность тут как раз в правильном прогресс-баре, тестировать просто копирование файлов я не вижу особого смысла.

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

(In reply to comment #19)
> Я склонюсь к мысли сделать простой вариант, отталкиваясь от количества файлов,
> а не их размера. Это будет не слишком плавный прогресс-бар, но общий прогресс
> выполнения работы вполне покажет.
Такая реализация в виде грязного наброска уже есть, но "в лоб" разъезд получился вида 140% вместо 102% (дело было ночером и уже внимания не хватило вникать, возможно, это были хардлинки -- оценка по du -i, счёт по выводу cp -av).

> Впрочем, поиграюсь еще с rsync, может получится взять размер файлов из его
> вывода.
Не трать зря время -- в свежайшем rsync вроде бы как что-то сделали, но ресурсоёмкое на начальном этапе; в сизифном мане соответствующие опции упоминаются, но бинарник отнекивается.  См. тж. http://serverfault.com/questions/219013/showing-total-progress-in-rsync-is-it-possible

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

Если хочешь, могу наброски попытаться выделить и прицепить -- просто этот вариант удобнее всего проверять в комплекте с дополненным ещё одним хуком профилем.

(В ответ на комментарий №19)
> Последний вариант патча похоже не рабочий. 

works for me.

Что не работает?

(В ответ на комментарий №20)
> (In reply to comment #19)
> > Я склонюсь к мысли сделать простой вариант, отталкиваясь от количества файлов,
> Такая реализация в виде грязного наброска уже есть, но "в лоб" разъезд
> получился вида 140% вместо 102% (дело было ночером и уже внимания не хватило
> вникать, возможно, это были хардлинки -- оценка по du -i, счёт по выводу cp
> -av).

И все-таки мне кажется это самым простым вариантом.

> > Впрочем, поиграюсь еще с rsync, может получится взять размер файлов из его
> > вывода.
> Не трать зря время -- в свежайшем rsync вроде бы как что-то сделали, но
> ресурсоёмкое на начальном этапе; в сизифном мане соответствующие опции
> упоминаются, но бинарник отнекивается.  См. тж.
> http://serverfault.com/questions/219013/showing-total-progress-in-rsync-is-it-possible

Да, я знаю. Похоже апстрим слишком рано обновил man page. Но может удастся обойтись и тем что есть.

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

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

(В ответ на комментарий №21)
> > Последний вариант патча похоже не рабочий. 
> works for me.
> Что не работает?

У меня в тестовом скрипте на базе этого патча прогресс начинался сразу с 80+ и быстро доходил до 100 задолго до конца работы.
Вообще checkpoints никакого отношения к размеру не имеют, если я правильно понял документацию.

(В ответ на комментарий №22)
> У меня в тестовом скрипте на базе этого патча прогресс начинался сразу с 80+ и
> быстро доходил до 100 задолго до конца работы.

Как это воспроизвести? С 80% может начинаться при размере самой большой директории <~100 блоков.

> Вообще checkpoints никакого отношения к размеру не имеют, если я правильно
> понял документацию.

--сheckpoint=X выводит число записанных блоков через каждые X записанных блоков.

> > У меня в тестовом скрипте на базе этого патча прогресс начинался сразу с 80+ и
> > быстро доходил до 100 задолго до конца работы.
> 
> Как это воспроизвести? С 80% может начинаться при размере самой большой
> директории <~100 блоков.

Не знаю, я просто копировал код из патча в тестовый скрипт. Но может где и ошибся.
В любом случае предложенный вариант выглядит слишком усложненным и не надежным.
У меня в гите есть простой вариант, где progress bar может и не такой плавный, но для данной задачи должно хватить.
Тестировал только тестовым скриптом, в самом alterator-livecd еще не проверял.

http://git.altlinux.org/people/sem/packages/?p=alterator-livecd.git;a=commit;h=33a273035ae6fd0ea21f257c6a5dde596726ccef

alterator-livecd-0.8.0-alt1 -> sisyphus:

* Thu Jan 10 2013 Mikhail Efremov <sem@altlinux> 0.8.0-alt1
- Don't use unsquashfs, just copy files (closes: #27786).