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

[Anton Farygin]

On 27.08.2020 23:29, Dmitry V. Levin wrote:
> On Thu, Aug 27, 2020 at 09:26:00PM +0300, Anton Farygin wrote:
>> On 27.08.2020 18:59, Dmitry V. Levin wrote:
>>> 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.
>>>
>> Отлично, а он как-то доступен снаружи ?
> Сейчас только во внутренней сети, но технически препятствий раздать наружу
> нет.

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

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