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> <068a17d6-e7d8-c66e-6dc8-c83155ae87e8@gmail.com> From: Anton Farygin Organization: BaseALT Message-ID: Date: Fri, 28 Aug 2020 08:03:53 +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: <068a17d6-e7d8-c66e-6dc8-c83155ae87e8@gmail.com> 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: Fri, 28 Aug 2020 05:03:53 -0000 Archived-At: List-Archive: List-Post: On 28.08.2020 03:58, Leonid Krivoshein wrote: > > > 27.08.2020 15:20, Dmitry V. Levin пишет: >> 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 есть ограничение на количество хардлинков, которе может быть >> у симлинка, я постарался это учесть. > > rm -rf ... всё же очень дорогая операция на изначально не 64-бит ФС. > В этом плане jfs рвёт её на части. Может, есть смысл бега для этих фс? > > Когда то давным давно я пробовал сделать зеркало архива на разных файловых системах. jfs умерла первой за ней с небольшим отрывом пошёл xfs на третьем месте оказался btrfs на втором пришёл zfs ext4 была быстрее всех. Тест был очень простой - заливались архивы (правда, без хардлинков для симлинков) и время от времени на произвольном таске делался du -s  zfs сейчас отлично справляется даже с включенным сжатием.