From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 27 Aug 2020 23:29:15 +0300 From: "Dmitry V. Levin" To: ALT Devel discussion list Message-ID: <20200827202915.GD6985@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> <5c47202d-a6cd-8b0e-39f1-c0a9d769a37b@basealt.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5c47202d-a6cd-8b0e-39f1-c0a9d769a37b@basealt.ru> Subject: Re: [devel] =?koi8-r?b?wdLIydfJ0s/Xwc7JxSDSxdDP2snUz9LJxdc=?= 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 20:29:16 -0000 Archived-At: List-Archive: List-Post: 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. > > > Отлично, а он как-то доступен снаружи ? Сейчас только во внутренней сети, но технически препятствий раздать наружу нет. -- ldv