From owner-freebsd-stable@FreeBSD.ORG Fri Jan 13 03:23:55 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45D73106566B; Fri, 13 Jan 2012 03:23:55 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from wilberforce.math.missouri.edu (wilberforce.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id 07AA08FC08; Fri, 13 Jan 2012 03:23:54 +0000 (UTC) Received: from [127.0.0.1] (wilberforce.math.missouri.edu [128.206.184.213]) by wilberforce.math.missouri.edu (8.14.5/8.14.5) with ESMTP id q0D3Nqot066507; Thu, 12 Jan 2012 21:23:52 -0600 (CST) (envelope-from stephen@missouri.edu) Message-ID: <4F0FA3C8.2020608@missouri.edu> Date: Thu, 12 Jan 2012 21:23:52 -0600 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Garrett Cooper References: <20120111161110.4258969c.rpclark@tds.net> <20120112200843.2a348d2f.rpclark@tds.net> <4F0F8E6F.8000909@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Andre Goree , Doug Barton , freebsd-stable@freebsd.org, Rob Clark Subject: Re: GENERIC make buildkernel error / fails - posix_fadvise X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 03:23:55 -0000 On 01/12/2012 09:11 PM, Garrett Cooper wrote: > +1. And it's faster yet when you can run parallel copies of rm on > different portions of the directory tree (e.g. xargs, find [..] -exec) > as rm is O(n). I have always wondered about that! I thought that the main bottleneck in "rm -r" might be deleting directories which are not in the disk cache, which then have to be copied from the disk. Copying two different parts of the disk into cache - well it has to be done one at a time whether the jobs asking for the copy of the disk are going concurrently or consecutively. And perhaps two instances of "rm -r" acting on different parts of the hard drive will cause disk thrashing, so that they might even slow each other down. But this is all guess work on my part. If I am wrong, and "rm -r" does work faster when working in parallel on different parts, then why doesn't someone write the "rm" command to fork copies of itself that work on different parts of large trees? Stephen