From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on sa.int.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 Date: Fri, 29 Oct 2010 15:06:27 +0300 From: "Kirill A. Shutemov" To: ALT Linux Team development discussions Message-ID: <20101029120627.GA22278@shutemov.name> References: <20101027065747.GA18226@altlinux.org> <20101028143817.4c4de84c@boyarsh.office.altlinux.ru> <20101028123759.GB17554@altlinux.org> <20101029001446.GC28162@altlinux.org> <4CCA5E0B.7050300@altlinux.com> <20101029100619.1bf95df6@boyarsh.office.altlinux.ru> <20101029095041.GE26409@altlinux.org> <20101029103951.GA5870@truecrux.org> <20101029115849.GA30305@altlinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20101029115849.GA30305@altlinux.org> User-Agent: Mutt/1.5.20 (2010-08-04) Subject: Re: [devel] I: git.alt update 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, 29 Oct 2010 12:06:32 -0000 Archived-At: List-Archive: List-Post: On Fri, Oct 29, 2010 at 03:58:49PM +0400, Dmitry V. Levin wrote: > On Fri, Oct 29, 2010 at 02:39:51PM +0400, Vladimir Lettiev wrote: > > On Fri, Oct 29, 2010 at 01:50:41PM +0400, Dmitry V. Levin wrote: > > > On Fri, Oct 29, 2010 at 10:06:19AM +0400, Anton V. Boyarshinov wrote: > > > > минут). Если продолжать в том же духе, машина умирает под грузом IO. > > > > > > Это ложный след. Если подкрутить настройки ФС, то и копирование Сизифа > > > стабилизируется на нескольких секундах. Ядро просто умирает через пару > > > часов без видимой причины. > > > > Вряд ли это ложный след. По крайне мере в приведённых ссылках на баги в ovz > > говорится о heavy file operations. > > Думаю параллельно с решением бага в ядре должна вестись работа над > > оптимизацией алгоритмов сборочницы, для снижения нагрузки на дисковую > > подсистему. > > Например, в случае cp -al можно заменить на алгоритм, который рекурсивно обходит > > все каталоги репозитория, делает ls в них и сравнивает с таким же выводом в > > локальной копии, и в соответствии с полученной информацией удаляет/копирует > > файлы. Нагрузка на дисковую подсистему минимальна. > > Рекурсивный обход всех каталогов репозитория -- это неминуемый stat на > каждый файл, если только не знать заранее, какие из этих файлов являются > каталогами. В данном случае, список (довольно короткий) каталогов известен заранее. Верно? -- Kirill A. Shutemov