Re: [devel] архивирование репозиториев

["Dmitry V. Levin" <ldv@altlinux.org>]

On Thu, Aug 27, 2020 at 03:32:53PM +0300, Anton Farygin wrote:
> On 27.08.2020 15:20, Dmitry V. Levin wrote:
> > On Thu, Aug 27, 2020 at 03:14:27PM +0300, Anton Farygin wrote:
> >> On 27.08.2020 15:09, Dmitry V. Levin wrote:
> >>> On Thu, Aug 27, 2020 at 02:59:22PM +0300, Anton Farygin wrote:
> >>>> On 27.08.2020 14:54, Andrey Savchenko wrote:
> >>>>> On Thu, 27 Aug 2020 10:27:11 +0300 Anton Farygin wrote:
> >>>>> [...]
> >>>>>> Т.е. - для экономии места старые пакеты хардлинкаются в новое место и в
> >>>>>> него уже добавляются изменения из сборочного задания. Очень простая и
> >>>>>> очень надёжная схема, при которой риск потери данных минимален и всегда
> >>>>>> можно взять консистентное состояние репозитория за любой момент времени.
> >>>>>>
> >>>>>> Живёт это всё сейчас, вроде как, на ext4 (я могу ошибаться).
> >>>>>> Максимальное количество inodes у ext4 2^32 - 4,294,967,295
> >>>>>>
> >>>>>> Каждый новый таск в репозиторий приводит к тому, что на файловой системе
> >>>>>> появляется около 160 тысяч (а может быть и больше, я давно не смотрел
> >>>>>> цифры) новых записей.
> >>>>>>
> >>>>>> Т.е. - условно мы можем записать около 26 тысяч сборочных заданий в
> >>>>>> архив, а после этого из него придётся удалять что-то старое для того,
> >>>>>> что бы записать что-то новое.
> >>>>> Это полная чушь, поскольку все жесткие ссылки на файл используют
> >>>>> один и тот же inode:
> >>>>>
> >>>>> https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Directory_Entries
> >>>>>
> >>>>> In an ext4 filesystem, a directory is more or less a flat file that
> >>>>> maps an arbitrary byte string (usually ASCII) to an inode number on
> >>>>> the filesystem. There can be many directory entries across the
> >>>>> filesystem that reference the same inode number--these are known as
> >>>>> hard links, and that is why hard links cannot reference files on
> >>>>> other filesystems. As such, directory entries are found by reading
> >>>>> the data block(s) associated with a directory file for the
> >>>>> particular directory entry that is desired.
> >>>>>
> >>>> Точно. Не хардлинки, а симлинки. Спасибо за замечание.
> >>> В архиваторе репозиториев используется захардлинкивание симлинков
> >>> для уменьшения количества используемых inode'ов.
> >> Ух ты, это же здорово. А где посмотреть исходники ?
> >>
> >> в girar я сходу это не увидел.
> > git grep GA_SYMLINK_DIR.
> >
> > В ext4 есть ограничение на количество хардлинков, которе может быть
> > у симлинка, я постарался это учесть.
> >
> Класс. Спасибо.
> 
> т.е. - моё предположение про inodes ошибочно и мы здесь не упрёмся. Т.е. 
> - в принципе ничего экстраординарного в большом росте количества заданий 
> за счёт роботов нет и архиватор это должен переварить (если опять, же 
> учитывать время на создание копии архива на файловой системе, которое 
> скорее всего не параллелится и упрётся просто в IO).
> 
> Я ведь правильно понял Игоря, что он хочет сборочницу, которая будет 
> пропускать десятки тысяч сборочных заданий в день ?
> 
> Представляю, какой адской задачей выглядит скопировать этот архив на 
> соседний сервер...
> 
> А нет ли внутри всей этой машинерии где-то хранилища, в котором собраны 
> все бинарные и исходные rpm пакеты за всю историю с именем, равным 
> какому-то хешу этого пакета ?
> 
> Что бы можно было скачать только его, а дальше раскрутить весь архив 
> скриптами по метаинформации из сборочных заданий.

Да, есть, называется depot.


-- 
ldv