From: Anton Farygin <rider@basealt.ru>
To: devel@lists.altlinux.org
Subject: Re: [devel] архивирование репозиториев
Date: Fri, 28 Aug 2020 10:09:37 +0300
Message-ID: <c970ee81-7ff3-7f65-7a52-fc23eb93bc0d@basealt.ru> (raw)
In-Reply-To: <20200827202915.GD6985@altlinux.org>
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.
>>>
>> Отлично, а он как-то доступен снаружи ?
> Сейчас только во внутренней сети, но технически препятствий раздать наружу
> нет.
Просто так раздавать не имеет смысла, а вот с журналом изменений - да,
было бы отлично.
Журнал можно в текстовом виде, просто что бы можно было выкачать только
изменения.
next prev parent reply other threads:[~2020-08-28 7:09 UTC|newest]
Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-27 2:29 [devel] incoming/girar: проблема производительности Igor Vlasenko
2020-08-27 7:27 ` Anton Farygin
2020-08-27 11:54 ` Andrey Savchenko
2020-08-27 11:59 ` Anton Farygin
2020-08-27 12:09 ` [devel] архивирование репозиториев Dmitry V. Levin
2020-08-27 12:14 ` Anton Farygin
2020-08-27 12:20 ` Dmitry V. Levin
2020-08-27 12:32 ` Anton Farygin
2020-08-27 15:59 ` Dmitry V. Levin
2020-08-27 18:26 ` Anton Farygin
2020-08-27 20:29 ` Dmitry V. Levin
2020-08-28 7:06 ` Alexey V. Vissarionov
2020-08-28 7:09 ` Anton Farygin [this message]
2020-08-27 17:31 ` Michael Shigorin
2020-08-27 17:51 ` Andrey Savchenko
2020-08-27 20:33 ` Dmitry V. Levin
2020-08-28 1:28 ` Dmitry V. Levin
2020-08-28 6:29 ` Andrey Savchenko
2020-08-29 2:04 ` Leonid Krivoshein
2020-08-28 0:58 ` Leonid Krivoshein
2020-08-28 1:11 ` Dmitry V. Levin
2020-08-29 2:16 ` Leonid Krivoshein
2020-08-28 5:03 ` Anton Farygin
2020-08-29 2:22 ` Leonid Krivoshein
2020-08-29 4:58 ` Anton Farygin
2020-08-29 14:18 ` Leonid Krivoshein
2020-08-29 16:23 ` Anton Farygin
2020-08-29 19:28 ` [devel] zfs " Vitaly Chikunov
2020-08-29 20:11 ` Anton Farygin
2020-08-29 20:38 ` Vitaly Chikunov
2020-08-29 21:12 ` Anton Farygin
2020-08-30 4:28 ` Alexey V. Vissarionov
2020-08-27 12:05 ` [devel] incoming/girar: проблема производительности Alexey V. Vissarionov
2020-08-28 9:25 ` Igor Vlasenko
2020-08-28 9:28 ` Anton V. Boyarshinov
2020-08-28 9:31 ` Igor Vlasenko
2020-08-28 9:34 ` Anton Farygin
2020-08-28 9:47 ` Igor Vlasenko
2020-08-27 9:17 ` Michael Shigorin
2020-08-28 0:23 ` [devel] mass rebuilds Dmitry V. Levin
2020-08-28 5:09 ` Anton Farygin
2020-08-28 6:25 ` Andrey Savchenko
2020-08-28 6:58 ` Anton Farygin
2020-08-28 16:46 ` Dmitry V. Levin
2020-08-28 20:23 ` Anton Farygin
2020-08-28 21:47 ` Dmitry V. Levin
2020-08-29 5:08 ` Anton Farygin
2020-08-27 9:57 ` [devel] incoming/girar: проблема производительности Dmitry V. Levin
2020-08-28 18:47 ` Dmitry V. Levin
2020-08-27 11:35 ` [devel] License Tag Policy (Re: incoming/girar: проблема =?utf-8?b?INC/0YDQvtC40LfQstC+0LTQuNGC0LXQu9GM0L3QvtGB0YLQuC4=?=) Sergey Afonin
2020-08-27 23:01 ` [devel] unmaintained packages shall not belong to Sisyphus Dmitry V. Levin
2020-08-28 0:04 ` Dmitry V. Levin
2020-08-28 0:35 ` Dmitry V. Levin
2020-08-28 5:22 ` Anton Farygin
2020-08-28 16:02 ` Dmitry V. Levin
2020-08-28 16:30 ` Michael Shigorin
2020-08-28 16:33 ` Michael Shigorin
2020-08-28 16:43 ` Dmitry V. Levin
2020-08-28 19:52 ` Michael Shigorin
2020-08-28 20:04 ` Dmitry V. Levin
2020-08-28 20:34 ` Michael Shigorin
2020-08-28 20:19 ` Alexey Gladkov
2020-08-28 20:46 ` Michael Shigorin
2020-08-28 23:52 ` Alexey Gladkov
2020-08-31 10:14 ` Konstantin Lepikhov
2020-08-31 18:09 ` [devel] [JT] баланс/динамика: пакеты/майнтейнеры (was: unmaintained packages shall not belong to Sisyphus) Michael Shigorin
2020-08-31 7:53 ` [devel] suggested tags order Aleksei Nikiforov
2020-08-31 11:46 ` Sergey V Turchin
2020-08-31 12:25 ` Paul Wolneykien
2020-08-28 16:40 ` [devel] hasher ALT#36531 Dmitry V. Levin
2020-08-30 0:15 ` Igor Vlasenko
2020-08-28 17:55 ` [devel] automatic License Dmitry V. Levin
2020-08-30 8:14 ` Igor Vlasenko
2020-08-30 10:09 ` Alexey Gladkov
2020-08-30 12:44 ` Igor Vlasenko
2020-08-30 15:21 ` Alexey Gladkov
2020-08-30 15:36 ` Michael Shigorin
2020-08-30 15:44 ` Alexey Gladkov
2020-08-30 15:58 ` Andrey Savchenko
2020-08-30 16:40 ` Alexey Gladkov
2020-08-30 17:27 ` Andrey Savchenko
2020-08-30 18:15 ` Alexey Gladkov
2020-08-30 18:47 ` Michael Shigorin
2020-08-30 17:56 ` Igor Vlasenko
2020-08-28 18:26 ` [devel] will be fatal in Perl 5.30 Dmitry V. Levin
2020-08-28 19:46 ` Michael Shigorin
2020-08-28 19:58 ` Dmitry V. Levin
2020-08-28 20:19 ` Michael Shigorin
2020-08-28 22:11 ` Dmitry V. Levin
2020-08-28 22:13 ` Dmitry V. Levin
2020-08-30 0:58 ` Igor Vlasenko
2020-08-30 0:41 ` Igor Vlasenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c970ee81-7ff3-7f65-7a52-fc23eb93bc0d@basealt.ru \
--to=rider@basealt.ru \
--cc=devel@lists.altlinux.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
ALT Linux Team development discussions
This inbox may be cloned and mirrored by anyone:
git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
public-inbox-index devel
Example config snippet for mirrors.
Newsgroup available over NNTP:
nntp://lore.altlinux.org/org.altlinux.lists.devel
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git