From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: To: devel@lists.altlinux.org References: <20200827022952.GA8129@dad.imath.kiev.ua> <5acc7f44-c122-d4ab-c67b-85275232f482@basealt.ru> <20200827145402.2cc954d1cb8412ffc81d9b11@altlinux.org> <5aa3cdd8-b3b0-a227-ed40-885636deab29@basealt.ru> <20200827120918.GA1072@altlinux.org> <20200827122039.GB1072@altlinux.org> <7419bdd7-bfb5-d073-19e1-7cc571f7427b@basealt.ru> <20200827155948.GB4007@altlinux.org> From: Anton Farygin Organization: BaseALT Message-ID: <5c47202d-a6cd-8b0e-39f1-c0a9d769a37b@basealt.ru> Date: Thu, 27 Aug 2020 21:26:00 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.1.1 MIME-Version: 1.0 In-Reply-To: <20200827155948.GB4007@altlinux.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: ru Subject: Re: [devel] =?utf-8?b?0LDRgNGF0LjQstC40YDQvtCy0LDQvdC40LUg0YDQtdC/?= =?utf-8?b?0L7Qt9C40YLQvtGA0LjQtdCy?= X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 18:26:01 -0000 Archived-At: List-Archive: List-Post: 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. > > Отлично, а он как-то доступен снаружи ?