[devel] Оптимизируем hasher для работы с фиксированным репозиторием. II.

[devel] Оптимизируем hasher для работы с фиксированным репозиторием. II.

[Igor Vlasenko]

Оптимизируем hasher для работы с фиксированным репозиторием. II.
________________________________________________________________

При запуске hasher, если hasher/cache/ уже есть,
то hasher проверяет, не изменился ли репозиторий, и если изменился,
то обновляет hasher/cache/, иначе использует hasher/cache/.

По условиям задачи у нас фиксированный репозиторий. Это означает,
что репозиторий не меняется без нашего ведома -- к примеру,
локальное зеркало ежедневного релиза Сизифа.

Вторая оптимизация позволяет ускорять любые работы с hasher.

Ее суть проста: поскольку мы явно знаем, что репозиторий не менялся,
то сообщить об этом hasher'у опцией вроде --same-repository,
чтобы он поверил человеку на слово, пропустил тяжелые проверки,
и сразу использовал свой hasher/cache/.

Немного статистики.

Проведем с hasher'ом 1.4.4-alt1 простые бенчмарки на машине altair
(2xXeon E5-2640v3). Репозиторий -- чистый Сизиф, рабочий каталог в tmpfs.
(первые измерения отбрасываем, чтобы исключить I/O с жестким диском).
Замеряем время hsh --initroot-only.

 mkdir $TMP/hasher
 time hsh $TMP/hasher --initroot-only --apt-config=/etc/autorepo/apt/apt.conf.Sisyphus.x86_64
Запуск hasher без кеша. hasher создает свой workdir, делает initroot.
18,98s user 5,54s system 104% cpu 23,503 total

 time hsh $TMP/hasher --initroot-only --apt-config=/etc/autorepo/apt/apt.conf.Sisyphus.x86_64
Запуск hasher с cache/. hasher проверяет свой workdir, делает initroot.
 6,36s user 2,73s system 103% cpu 8,805 total
hasher-1.4.4, кстати, здесь быстрее (9сек), чем hasher-1.4.3 (10.5сек).
Когда я начинал замеры, то пользовался установленным 1.4.3,
но на всякий случай проверил, последняя ли это версия, обновился,
и далее пользовался уже 1.4.4, в которой Дмитрий сумел уменьшить это
время на 1.5 секунды.
Не думайте об этих секундах свысока. Экономия в 1.5 секунды по
сравнению с hasher-1.4.3 каждый раз при сборке или проверке установкой
при пересборке питона для 1000+ исходных и 3500+ бинарных пакетов
даст почти два часа ускорения сборки этой транзакции на x86_64.
Мне же удалось сэкономить 8.3 секунды на initroot, выполняя его за 2.2с
(0,033 total+2,131 total).
Это близко к нижнему пределу. Если репозиторий, с которым проводилась
сборка, не менялся, то по умолчанию (--without-stuff), hasher должен
обновить chroot, а выполнить cpio --extract на hasher/.../chroot.cpio
занимает
 lz4 -d chroot.cpio | time cpio --extract [...]
0,16s user 0,95s system 74% cpu 1,486 total

Эта оптимизация естественно просится в сборочницу.
Ведь в процессе сборки task'а репозиторий, с которым проводится
сборка, не меняется. Даже если за это время Сизиф обновится,
сборка все равно будет идти на старом репозитории.

Секунды к секундам экономии дадут больше 8 часов ускорения
пересборки питона или больше 3 часов ускорения пересборки perl.
На одиночном таске это ускорение не так заметно. Пакеты наподобие
hplip соберутся быстрее на минуту-полторы, но выстроившаяся
очередь в сборочницу соберется существенно быстрее, ведь
в очереди экономия суммируется.

К сожалению, эта оптимизации нет в нашем hasher'е. Она существует в
виде моего приватного форка. В сборочнице для autoimports
для ускорения работы с hasher initroot выполнялся только один раз,
при старте. Полученный hasher_workdir в параллельных потоках
клонировался (см. предыдущее письмо: subj часть. I.)
и далее сборчница работала напрямую с hsh-rebuild и hsh-install.
Свои изменения я оформил в 2 низкоуровневых патча, отключающих
2 тяжелые проверки с кешем hasher.
Для пробы попытался провести более простой патч в апстрим hasher,
https://bugzilla.altlinux.org/show_bug.cgi?id=36531
Но не смог.
Тогда я занимался переписыванием своей сборочницы для autoimports
в полноценную дистрибутивную (локальную) сборочницу для всех желающих.
Забросил это переписывание, когда понял, что, помимо сборочницы,
придется, по сути, поддерживать собственный форк hasher,
что явно было чересчур.

Впрочем, тогда я сам понимал и позиционировал в #36531 эти патчи как
ускорение работы с клонированным hasher_workdir. Сейчас, разбираясь,
я замерил задержки с оригинальным и клонированным hasher_workdir --
они оказались одинаковыми, клонирование здесь не при чем,
Переосмысливая, это просто общее ускорение работы hasher с
фиксированным репозиторием. При этом вместо двух низкоуровневых
опций возможно была бы уместнее одна высокоуровневая
вроде --same-repository.

Кроме того, эти проверки в hasher, возможно, содержат какие-то
логические ошибки. Вспомнилось, что полтора года назад при отладке
внутри упомянутых проверок сравнивались списки пакетов, которые
почему-то были различными при первом запуске без cache/ и втором
запуске с cache/, при том, что репозиторий не менялся.
Это приводило к выполнению ненужных тяжелых операций,
которые я отключил вместе с проверками. Тогда я эти странности
списал на неправильное клонирование, но бенчмарки показали,
что это не так.

В общем, мне бы очень хотелось избавиться от своего форка hasher
и получить ту же функциональность от пакета hasher в Sisyphus.

-- 

I V

Re: [devel] Оптимизируем hasher для работы с фиксированным репозиторием. II.

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 10316 bytes --]

Добрый день!

On Tue, 8 Sep 2020 03:12:33 +0300 Igor Vlasenko wrote:
> Оптимизируем hasher для работы с фиксированным репозиторием. II.
> ________________________________________________________________
> 
> При запуске hasher, если hasher/cache/ уже есть,
> то hasher проверяет, не изменился ли репозиторий, и если изменился,
> то обновляет hasher/cache/, иначе использует hasher/cache/.
> 
> По условиям задачи у нас фиксированный репозиторий. Это означает,
> что репозиторий не меняется без нашего ведома -- к примеру,
> локальное зеркало ежедневного релиза Сизифа.
> 
> Вторая оптимизация позволяет ускорять любые работы с hasher.
> 
> Ее суть проста: поскольку мы явно знаем, что репозиторий не менялся,
> то сообщить об этом hasher'у опцией вроде --same-repository,
> чтобы он поверил человеку на слово, пропустил тяжелые проверки,
> и сразу использовал свой hasher/cache/.
> 
> Немного статистики.
> 
> Проведем с hasher'ом 1.4.4-alt1 простые бенчмарки на машине altair
> (2xXeon E5-2640v3). Репозиторий -- чистый Сизиф, рабочий каталог в tmpfs.
> (первые измерения отбрасываем, чтобы исключить I/O с жестким диском).
> Замеряем время hsh --initroot-only.
> 
>  mkdir $TMP/hasher
>  time hsh $TMP/hasher --initroot-only --apt-config=/etc/autorepo/apt/apt.conf.Sisyphus.x86_64
> Запуск hasher без кеша. hasher создает свой workdir, делает initroot.
> 18,98s user 5,54s system 104% cpu 23,503 total
> 
>  time hsh $TMP/hasher --initroot-only --apt-config=/etc/autorepo/apt/apt.conf.Sisyphus.x86_64
> Запуск hasher с cache/. hasher проверяет свой workdir, делает initroot.
>  6,36s user 2,73s system 103% cpu 8,805 total
> hasher-1.4.4, кстати, здесь быстрее (9сек), чем hasher-1.4.3 (10.5сек).
> Когда я начинал замеры, то пользовался установленным 1.4.3,
> но на всякий случай проверил, последняя ли это версия, обновился,
> и далее пользовался уже 1.4.4, в которой Дмитрий сумел уменьшить это
> время на 1.5 секунды.
> Не думайте об этих секундах свысока. Экономия в 1.5 секунды по
> сравнению с hasher-1.4.3 каждый раз при сборке или проверке установкой
> при пересборке питона для 1000+ исходных и 3500+ бинарных пакетов
> даст почти два часа ускорения сборки этой транзакции на x86_64.
> Мне же удалось сэкономить 8.3 секунды на initroot, выполняя его за 2.2с
> (0,033 total+2,131 total).
> Это близко к нижнему пределу. Если репозиторий, с которым проводилась
> сборка, не менялся, то по умолчанию (--without-stuff), hasher должен
> обновить chroot, а выполнить cpio --extract на hasher/.../chroot.cpio
> занимает
>  lz4 -d chroot.cpio | time cpio --extract [...]
> 0,16s user 0,95s system 74% cpu 1,486 total
> 
> Эта оптимизация естественно просится в сборочницу.
> Ведь в процессе сборки task'а репозиторий, с которым проводится
> сборка, не меняется. Даже если за это время Сизиф обновится,
> сборка все равно будет идти на старом репозитории.

Оптимизация хорошая и я думаю, что эта опция нам нужна в hasher,
т.к. будет полезна ряду пользователей.

Однако, хочу отметить, что репозиторий внутри таска тоже может
меняться: например, в таске есть пакеты A и B, A собирается перед B
и A находится в сборочных зависимостях B. Тогда после сборки A
репозиторий внутри таска изменится и B будет собираться уже в другом
окружении. Поэтому просто так на сборочнице включать эту опцию
нельзя.

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

> Секунды к секундам экономии дадут больше 8 часов ускорения
> пересборки питона или больше 3 часов ускорения пересборки perl.
> На одиночном таске это ускорение не так заметно. Пакеты наподобие
> hplip соберутся быстрее на минуту-полторы, но выстроившаяся
> очередь в сборочницу соберется существенно быстрее, ведь
> в очереди экономия суммируется.
> 
> К сожалению, эта оптимизации нет в нашем hasher'е. Она существует в
> виде моего приватного форка. В сборочнице для autoimports
> для ускорения работы с hasher initroot выполнялся только один раз,
> при старте. Полученный hasher_workdir в параллельных потоках
> клонировался (см. предыдущее письмо: subj часть. I.)
> и далее сборчница работала напрямую с hsh-rebuild и hsh-install.
> Свои изменения я оформил в 2 низкоуровневых патча, отключающих
> 2 тяжелые проверки с кешем hasher.
> Для пробы попытался провести более простой патч в апстрим hasher,
> https://bugzilla.altlinux.org/show_bug.cgi?id=36531
> Но не смог.
> Тогда я занимался переписыванием своей сборочницы для autoimports
> в полноценную дистрибутивную (локальную) сборочницу для всех желающих.
> Забросил это переписывание, когда понял, что, помимо сборочницы,
> придется, по сути, поддерживать собственный форк hasher,
> что явно было чересчур.
> 
> Впрочем, тогда я сам понимал и позиционировал в #36531 эти патчи как
> ускорение работы с клонированным hasher_workdir. Сейчас, разбираясь,
> я замерил задержки с оригинальным и клонированным hasher_workdir --
> они оказались одинаковыми, клонирование здесь не при чем,
> Переосмысливая, это просто общее ускорение работы hasher с
> фиксированным репозиторием. При этом вместо двух низкоуровневых
> опций возможно была бы уместнее одна высокоуровневая
> вроде --same-repository.
> 
> Кроме того, эти проверки в hasher, возможно, содержат какие-то
> логические ошибки. Вспомнилось, что полтора года назад при отладке
> внутри упомянутых проверок сравнивались списки пакетов, которые
> почему-то были различными при первом запуске без cache/ и втором
> запуске с cache/, при том, что репозиторий не менялся.
> Это приводило к выполнению ненужных тяжелых операций,
> которые я отключил вместе с проверками. Тогда я эти странности
> списал на неправильное клонирование, но бенчмарки показали,
> что это не так.
> 
> В общем, мне бы очень хотелось избавиться от своего форка hasher
> и получить ту же функциональность от пакета hasher в Sisyphus.
> 


Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] Оптимизируем hasher для работы с фиксированным репозиторием. II.

[Michael Shigorin]

On Tue, Sep 08, 2020 at 01:03:10PM +0300, Andrey Savchenko wrote:
> Для корректного применения этой опции необходимо иметь
> возможность построить граф сборочных зависимостей для каждого
> подзадания после первого и определить, нет ли в нём пакетов,
> полученных в предшествующих подзаданиях.

Здесь сходу видна один простой достаточно общий случай:
для заданий с одним подзаданием можно просто включать.

> Проблема в том, что, как уже обсуждалось в данной рассылке,
> в общем случае это неразрешимая задача, т.к. зависимости у нас
> есть не только явно на пакеты, но и на другие объекты,
> например, библиотеки или модули pkg-config: это плата, которую
> нам приходится платить за механизм автоматического определения
> зависимостей.

Сейчас на сборочнице включена перепаковка исходного пакета
для выяснения сборочных зависимостей с учётом %ifarch и т.п.;
не помню, получится ли повторно использовать затраты ресурсов
на эту фазу, но вдруг.

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

Но это всё слова...

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] Оптимизируем hasher для работы с фиксированным репозиторием. II.

[Igor Vlasenko]

On Tue, Sep 08, 2020 at 01:03:10PM +0300, Andrey Savchenko wrote:
> Однако, хочу отметить, что репозиторий внутри таска тоже может
> меняться: например, в таске есть пакеты A и B, A собирается перед B
> и A находится в сборочных зависимостях B. Тогда после сборки A
> репозиторий внутри таска изменится и B будет собираться уже в другом
> окружении. Поэтому просто так на сборочнице включать эту опцию
> нельзя.

Это не является изменением внешнего репозитория. Это просто --with-stuff
сборка hasher'ом. Перевыпуск нового сизифа сборчница делает после всего 
таска, а не после пакета А.

Можно привести такой пример.
Я скачал зеркало Сизифа и собрал в hasher --with-stuff пакеты A и B.
A собирается перед B и A находится в сборочных зависимостях B. 
Тогда после сборки A репозиторий RPMS.hasher изменится и B
будет собираться уже в другом окружении. 

_НО_! мое зеркало Сизифа ведь никак не изменится?
hasher/aptbox/var/lib/apt/lists/ не изменится.
hasher/cache/chroot/chroot.cpio не изменится (если мы не собирали
ограниченный список пакетов из basesystem).

Поэтому и для опции --with-stuff оптимизация --same-repository
имеет смысл. Раз по сути и --with-stuff в hasher/cache/ 
почти ничего не поменяется, то опять достаточно только 2 операции:
1) распаковать chroot.cpio, как и с --without-stuff,
и 
2) переиндексировать hasher/repo/*/RPMS.hasher: обновить
hasher/cache/contents/parts/_tmp_.private_*_hasher_repo_x86_64_RPMS.hasher_
hasher/cache/contents/contents_index_bin

Поэтому оптимизация --same-repository применима и с --with-stuff,
и в частности в сборчнице, если в таске нет пакетов из chroot.cpio.


-- 

I V

Re: [devel] Оптимизируем hasher для работы с фиксированным репозиторием. II.

[Alexey V. Vissarionov]

On 2020-09-08 14:30:30 +0300, Igor Vlasenko wrote:

 > Поэтому оптимизация --same-repository применима и с --with-stuff

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

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


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] Оптимизируем hasher для работы с фиксированным репозиторием. II.

[Igor Vlasenko]

On Tue, Sep 08, 2020 at 03:18:22PM +0300, Alexey V. Vissarionov wrote:
> Игорь, большая просьба: назовите эту опцию хотя бы --fixed-repo
> (так будет намного правильнее с языковой кочки зрения).

Спасибо, поправлю.

-- 

I V

Re: [devel] Оптимизируем hasher для работы с фиксированным репозиторием. II.

[Anton Farygin]

On 08.09.2020 17:37, Igor Vlasenko wrote:
> On Tue, Sep 08, 2020 at 03:18:22PM +0300, Alexey V. Vissarionov wrote:
>> Игорь, большая просьба: назовите эту опцию хотя бы --fixed-repo
>> (так будет намного правильнее с языковой кочки зрения).
> Спасибо, поправлю.
>
тогда уж stale-repo, это будет честнее.

Re: [devel] Оптимизируем hasher для работы с фиксированным репозиторием. II.

[Paul Wolneykien]

В Tue, 8 Sep 2020 17:39:14 +0300
Anton Farygin <rider@basealt.ru> пишет:

> On 08.09.2020 17:37, Igor Vlasenko wrote:
> > On Tue, Sep 08, 2020 at 03:18:22PM +0300, Alexey V. Vissarionov
> > wrote:  
> >> Игорь, большая просьба: назовите эту опцию хотя бы --fixed-repo
> >> (так будет намного правильнее с языковой кочки зрения).  
> > Спасибо, поправлю.
> >  
> тогда уж stale-repo, это будет честнее.

  IMHO, опция должна называть то, что *делать* программе, а не давать
характеристику стороннему объекту.

Re: [devel] Оптимизируем hasher для работы с фиксированным репозиторием. II.

[Anton Farygin]

On 08.09.2020 17:54, Paul Wolneykien wrote:
> В Tue, 8 Sep 2020 17:39:14 +0300
> Anton Farygin <rider@basealt.ru> пишет:
>
>> On 08.09.2020 17:37, Igor Vlasenko wrote:
>>> On Tue, Sep 08, 2020 at 03:18:22PM +0300, Alexey V. Vissarionov
>>> wrote:
>>>> Игорь, большая просьба: назовите эту опцию хотя бы --fixed-repo
>>>> (так будет намного правильнее с языковой кочки зрения).
>>> Спасибо, поправлю.
>>>   
>> тогда уж stale-repo, это будет честнее.
>    IMHO, опция должна называть то, что *делать* программе, а не давать
> характеристику стороннему объекту.

Кстати да.

Паша точно заметил.

Re: [devel] Оптимизируем hasher для работы с фиксированным репозиторием. II.

[Dmitry V. Levin]

On Tue, Sep 08, 2020 at 03:12:33AM +0300, Igor Vlasenko wrote:
> Оптимизируем hasher для работы с фиксированным репозиторием. II.
> ________________________________________________________________
> 
> При запуске hasher, если hasher/cache/ уже есть,
> то hasher проверяет, не изменился ли репозиторий, и если изменился,
> то обновляет hasher/cache/, иначе использует hasher/cache/.
> 
> По условиям задачи у нас фиксированный репозиторий. Это означает,
> что репозиторий не меняется без нашего ведома -- к примеру,
> локальное зеркало ежедневного релиза Сизифа.
> 
> Вторая оптимизация позволяет ускорять любые работы с hasher.
> 
> Ее суть проста: поскольку мы явно знаем, что репозиторий не менялся,
> то сообщить об этом hasher'у опцией вроде --same-repository,
> чтобы он поверил человеку на слово, пропустил тяжелые проверки,
> и сразу использовал свой hasher/cache/.

Я думаю, что поддержка $unchecked_initroot_cache, которая была реализована
весной прошлого года в hasher-1.3.36, предназначена для решения именно
этой задачи.  Эта оптимизация используется в install check на сборочнице.

Пример использования:
unchecked_initroot_cache="$(sed '/^task[[:space:]]\+/!d;s///;q' /path/to/Sisyphus/files/list/task.info)"


-- 
ldv

Re: [devel] Оптимизируем hasher для работы с фиксированным репозиторием. II.

[Anton Farygin]

On 08.09.2020 18:01, Dmitry V. Levin wrote:
> On Tue, Sep 08, 2020 at 03:12:33AM +0300, Igor Vlasenko wrote:
>> Оптимизируем hasher для работы с фиксированным репозиторием. II.
>> ________________________________________________________________
>>
>> При запуске hasher, если hasher/cache/ уже есть,
>> то hasher проверяет, не изменился ли репозиторий, и если изменился,
>> то обновляет hasher/cache/, иначе использует hasher/cache/.
>>
>> По условиям задачи у нас фиксированный репозиторий. Это означает,
>> что репозиторий не меняется без нашего ведома -- к примеру,
>> локальное зеркало ежедневного релиза Сизифа.
>>
>> Вторая оптимизация позволяет ускорять любые работы с hasher.
>>
>> Ее суть проста: поскольку мы явно знаем, что репозиторий не менялся,
>> то сообщить об этом hasher'у опцией вроде --same-repository,
>> чтобы он поверил человеку на слово, пропустил тяжелые проверки,
>> и сразу использовал свой hasher/cache/.
> Я думаю, что поддержка $unchecked_initroot_cache, которая была реализована
> весной прошлого года в hasher-1.3.36, предназначена для решения именно
> этой задачи.  Эта оптимизация используется в install check на сборочнице.
>
> Пример использования:
> unchecked_initroot_cache="$(sed '/^task[[:space:]]\+/!d;s///;q' /path/to/Sisyphus/files/list/task.info)"
>
а можно для тупых объяснить что это делает и как ?

Опцией было бы понятнее, конечно.

Re: [devel] hasher unchecked_initroot_cache

[Dmitry V. Levin]

On Tue, Sep 08, 2020 at 06:09:11PM +0300, Anton Farygin wrote:
> On 08.09.2020 18:01, Dmitry V. Levin wrote:
> > On Tue, Sep 08, 2020 at 03:12:33AM +0300, Igor Vlasenko wrote:
> >> Оптимизируем hasher для работы с фиксированным репозиторием. II.
> >> ________________________________________________________________
> >>
> >> При запуске hasher, если hasher/cache/ уже есть,
> >> то hasher проверяет, не изменился ли репозиторий, и если изменился,
> >> то обновляет hasher/cache/, иначе использует hasher/cache/.
> >>
> >> По условиям задачи у нас фиксированный репозиторий. Это означает,
> >> что репозиторий не меняется без нашего ведома -- к примеру,
> >> локальное зеркало ежедневного релиза Сизифа.
> >>
> >> Вторая оптимизация позволяет ускорять любые работы с hasher.
> >>
> >> Ее суть проста: поскольку мы явно знаем, что репозиторий не менялся,
> >> то сообщить об этом hasher'у опцией вроде --same-repository,
> >> чтобы он поверил человеку на слово, пропустил тяжелые проверки,
> >> и сразу использовал свой hasher/cache/.
> > Я думаю, что поддержка $unchecked_initroot_cache, которая была реализована
> > весной прошлого года в hasher-1.3.36, предназначена для решения именно
> > этой задачи.  Эта оптимизация используется в install check на сборочнице.
> >
> > Пример использования:
> > unchecked_initroot_cache="$(sed '/^task[[:space:]]\+/!d;s///;q' /path/to/Sisyphus/files/list/task.info)"
> >
> а можно для тупых объяснить что это делает и как ?

unchecked_initroot_cache - это конфигурационная настройка, похожая на
конфигурационную настройку no_cache, только к no_cache есть cli в виде
--no-cache, а к unchecked_initroot_cache нет.

В пояснении к unchecked_initroot_cache написано следующее:

# Whether the initroot cache is unchecked.
# Unchecked initroot cache allows more efficient initroot caching,
# but its validity is the responsibility of the user.

По умолчанию значением unchecked_initroot_cache является пустая строка.
Если unchecked_initroot_cache имеет значение, отличное от пустой строки,
то hasher сравнивает это значение со значением unchecked_initroot_cache,
которое было на момент создания cache, и если эти значения совпадают, то
обычная проверка актуальности cache не производится.

Настройку вида
unchecked_initroot_cache="$(sed '/^task[[:space:]]\+/!d;s///;q' /path/to/Sisyphus/files/list/task.info)"
не рекомендуется использовать без --without-stuff по очевидной причине.

> Опцией было бы понятнее, конечно.

Есть мнение, что контролировать эту настройку с помощью cli не очень
удобно, но если будет предложен удачный вариант cli, то я не против.


-- 
ldv

Re: [devel] hasher unchecked_initroot_cache

[Igor Vlasenko]

On Tue, Sep 08, 2020 at 10:05:30PM +0300, Dmitry V. Levin wrote:
> не рекомендуется использовать без --without-stuff по очевидной причине.
> 
> > Опцией было бы понятнее, конечно.
> 
> Есть мнение, что контролировать эту настройку с помощью cli не очень
> удобно, но если будет предложен удачный вариант cli, то я не против.

Спасибо, буду думать.

-- 

I V

Re: [devel] Оптимизируем hasher для работы с фиксированным репозиторием. II.

[Igor Vlasenko]

On Tue, Sep 08, 2020 at 06:01:37PM +0300, Dmitry V. Levin wrote:
> Я думаю, что поддержка $unchecked_initroot_cache, которая была реализована
> весной прошлого года в hasher-1.3.36, предназначена для решения именно
> этой задачи.  Эта оптимизация используется в install check на сборочнице.
> 
> Пример использования:
> unchecked_initroot_cache="$(sed '/^task[[:space:]]\+/!d;s///;q' /path/to/Sisyphus/files/list/task.info)"

предназначена, но решает ли?
1) в таком виде это хак для сборочницы.
Реализация завязана на cookie файл, который обычным
hasher не создается. Тем более нет опции пользователя.
Будет ли работать этот хак в дистрибутивной сборочнице,
для всяческих карманов?

2) в моем форке hasher-1.3.34 было 2 патча, там в 2-х
местах происходила потеря времени. Один из патчей
похоже, эквивалентен unchecked_initroot_cache,
только с опцией пользователя. Второй надо будет
отребазить на свежий hasher, посмотреть, что получится.

Дмитрий, вы проводили benchmarks, на сколько сокращается время?
Есть ли еще существенная разница сo cpio --extract ?

И хотелось бы нормальную ручку. --fixed-repository критиковали,
--force-cache может быть?

Будет высокоуровневая ручка, можно будет не торопясь провести
отладку, улучшить тайминги, интерфейс ведь уже меняться не будет.

-- 

I V

Re: [devel] Оптимизируем hasher для работы с фиксированным репозиторием. II.

[Gleb Fotengauer-Malinovskiy]

[-- Attachment #1: Type: text/plain, Size: 1668 bytes --]

Hi,

On Tue, Sep 08, 2020 at 07:14:38PM +0300, Igor Vlasenko wrote:
> On Tue, Sep 08, 2020 at 06:01:37PM +0300, Dmitry V. Levin wrote:
> > Я думаю, что поддержка $unchecked_initroot_cache, которая была реализована
> > весной прошлого года в hasher-1.3.36, предназначена для решения именно
> > этой задачи.  Эта оптимизация используется в install check на сборочнице.
> > 
> > Пример использования:
> > unchecked_initroot_cache="$(sed '/^task[[:space:]]\+/!d;s///;q' /path/to/Sisyphus/files/list/task.info)"
> 
> предназначена, но решает ли?
> 1) в таком виде это хак для сборочницы.
> Реализация завязана на cookie файл, который обычным
> hasher не создается.

Это же не реализация, это пример использования.

> Тем более нет опции пользователя.
> Будет ли работать этот хак в дистрибутивной сборочнице,
> для всяческих карманов?

Вы можете вообще написать unchecked_initroot_cache=1 и делать hsh --clean
внешними инструментами когда у вас меняются источники.
А можно, наоборот, делать в этом месте stat всем release-файлам
репозиториев-источников от локального репозитория.

-- 
glebfm

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] Оптимизируем hasher для работы с фиксированным репозиторием. II.

[Igor Vlasenko]

On Tue, Sep 08, 2020 at 07:38:36PM +0300, Gleb Fotengauer-Malinovskiy wrote:
> Это же не реализация, это пример использования.

В принципе, вопрос с пользовательской опцией
стоит, наверное, отложить.

Я в первую очередь хочу избавиться от своего форка hasher.
Первый шаг уже сделан, я разобрался, что в свое время делал
с hasher-1.3.34, и документировал это в рассылке.

В процессе обсуждения Дмитрий заметил, что один из
патчей скорее всего уже реализован с версии 1.3.36.
Теперь мне надо перенести те изменения на hasher-1.4.4,
протестировать, актуален ли второй патч,
и если актуален, то продолжить процедуру слияния.
Вопрос с пользовательской ручкой стоит отложить.
Если достаточно хака в одном месте, то ручка наверное
не нужна. Если же нужно будет хакать в 2-х и более
местах, то для каждого такого места будет
достаточно тайной переменной, а вот для их
одновременного включения лучше будет высокоуровневая ручка.

Поэтому возьму паузу на rebase и отладку.

-- 

I V

Re: [devel] Оптимизируем hasher для работы с фиксированным репозиторием. II.

[Dmitry V. Levin]

On Tue, Sep 08, 2020 at 07:14:38PM +0300, Igor Vlasenko wrote:
> On Tue, Sep 08, 2020 at 06:01:37PM +0300, Dmitry V. Levin wrote:
> > Я думаю, что поддержка $unchecked_initroot_cache, которая была реализована
> > весной прошлого года в hasher-1.3.36, предназначена для решения именно
> > этой задачи.  Эта оптимизация используется в install check на сборочнице.
> > 
> > Пример использования:
> > unchecked_initroot_cache="$(sed '/^task[[:space:]]\+/!d;s///;q' /path/to/Sisyphus/files/list/task.info)"
> 
> предназначена, но решает ли?
> 1) в таком виде это хак для сборочницы.

Этот пример был не из сборочницы, а из моей обычной hasher'ницы,
в которой рядом есть настройка no_stuff=1.


-- 
ldv

Re: [devel] Оптимизируем hasher для работы с фиксированным репозиторием. II.

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1400 bytes --]

On Tue, 8 Sep 2020 22:11:44 +0300 Dmitry V. Levin wrote:
> On Tue, Sep 08, 2020 at 07:14:38PM +0300, Igor Vlasenko wrote:
> > On Tue, Sep 08, 2020 at 06:01:37PM +0300, Dmitry V. Levin wrote:
> > > Я думаю, что поддержка $unchecked_initroot_cache, которая была реализована
> > > весной прошлого года в hasher-1.3.36, предназначена для решения именно
> > > этой задачи.  Эта оптимизация используется в install check на сборочнице.
> > > 
> > > Пример использования:
> > > unchecked_initroot_cache="$(sed '/^task[[:space:]]\+/!d;s///;q' /path/to/Sisyphus/files/list/task.info)"
> > 
> > предназначена, но решает ли?
> > 1) в таком виде это хак для сборочницы.
> 
> Этот пример был не из сборочницы, а из моей обычной hasher'ницы,
> в которой рядом есть настройка no_stuff=1.

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

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] Оптимизируем hasher для работы с фиксированным репозиторием. II.

[Dmitry V. Levin]

On Wed, Sep 09, 2020 at 08:21:47AM +0300, Andrey Savchenko wrote:
> On Tue, 8 Sep 2020 22:11:44 +0300 Dmitry V. Levin wrote:
> > On Tue, Sep 08, 2020 at 07:14:38PM +0300, Igor Vlasenko wrote:
> > > On Tue, Sep 08, 2020 at 06:01:37PM +0300, Dmitry V. Levin wrote:
> > > > Я думаю, что поддержка $unchecked_initroot_cache, которая была реализована
> > > > весной прошлого года в hasher-1.3.36, предназначена для решения именно
> > > > этой задачи.  Эта оптимизация используется в install check на сборочнице.
> > > > 
> > > > Пример использования:
> > > > unchecked_initroot_cache="$(sed '/^task[[:space:]]\+/!d;s///;q' /path/to/Sisyphus/files/list/task.info)"
> > > 
> > > предназначена, но решает ли?
> > > 1) в таком виде это хак для сборочницы.
> > 
> > Этот пример был не из сборочницы, а из моей обычной hasher'ницы,
> > в которой рядом есть настройка no_stuff=1.
> 
> С своей хешернице я бы хотел видеть более читаемый код, чем кошмар,
> процитированный выше. Мне не хочется каждый раз ломать мозг на
> тему, а что же эта штука делает.

Это дело вкуса.  Замените sed на какой-нибудь b2sum, если так будет понятнее.


-- 
ldv