From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1RUIZ0-0006iq-25 for garchives@archives.gentoo.org; Sat, 26 Nov 2011 13:45:06 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2892321C11F; Sat, 26 Nov 2011 13:44:57 +0000 (UTC) Received: from mail-bw0-f53.google.com (mail-bw0-f53.google.com [209.85.214.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 5607021C02B for ; Sat, 26 Nov 2011 13:44:29 +0000 (UTC) Received: by bkaq10 with SMTP id q10so6811815bka.40 for ; Sat, 26 Nov 2011 05:44:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=HHeKhRmQJxVYhvwEgq1K7cqcn1eY0GpJ6u12+XBESsU=; b=f4H1k/x/CyVE+OXyyvVBabttutyQgjo+NGnAVdH6+8rJlnF+AS9+MSvW/Y8/kI2hlP bJetT0Q5nzBFrTw1gXiXEwME8wdl7p5n4xhzFWeHXNOfDsj417tHJryKqBw+nxJxcJQ/ BI6Zm0+SyJTXb3NbAf+9lWX5Tw3yaJxM9d29A= Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Received: by 10.205.127.77 with SMTP id gz13mr24459273bkc.76.1322315068431; Sat, 26 Nov 2011 05:44:28 -0800 (PST) Sender: freemanrich@gmail.com Received: by 10.204.121.2 with HTTP; Sat, 26 Nov 2011 05:44:28 -0800 (PST) In-Reply-To: <20111126125915.428cb31a@googlemail.com> References: <1d4ac47c28706094230cb2c4e6ee1c1c71629aa0.arfrever@gentoo> <20111126105822.GA37825@gentoo.org> <20111126113830.GC37825@gentoo.org> <20111126125915.428cb31a@googlemail.com> Date: Sat, 26 Nov 2011 08:44:28 -0500 X-Google-Sender-Auth: noPt4GpTNQoNraL5z4YxZ2sIy-0 Message-ID: Subject: Re: [gentoo-dev] Re: proj/portage:master commit in: pym/portage/dbapi/ From: Rich Freeman To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=ISO-8859-1 X-Archives-Salt: fc7a355f-49ab-4f65-b1a4-c764a6156459 X-Archives-Hash: c11ecb5c701584298d873ac29bb16d3a On Sat, Nov 26, 2011 at 7:59 AM, Ciaran McCreesh wrote: > On Sat, 26 Nov 2011 18:20:27 +0530 > Nirbheek Chauhan wrote: >> Actually, reading the code it seems that it's about the file merge >> order of a single package. My participation in this entire discussion >> is m00t. Never mind. :p > > ...in which case it's often an awful lot faster to sort by inode, not by > filename. Try it when installing a kernel sources package. I can believe it. Btrfs added inode-order directory indexes precisely for this reason. I'd have to look up the details but I think it was designed to return the directories in this order to function calls so that anything that iterates through the tree would get this optimization by default. Of course, if you then resort the list first you lose that. (It also has the ext3 dir_index-style indexes for named file lookups.) Oh, on the topic of btrfs, if any emerge operations do file copies, adding --reflink=auto to the cp command will GREATLY improve performance. That does a copy-on-write copy - it behaves like a hard-link as far as time to create goes, but it behaves like a full copy as far as modifications not being shared goes. It also uses almost no additional disk space until the content starts to diverge between the copies. Setting reflink=auto should be safe on non-COW filesystems as it will fall back to a normal copy if the operation isn't supported. It is available in stable coreutils. Some speculate that this option could increase fragmentation (both copies will share extents from the original file, and have some extents of their own), but btrfs doesn't overwrite anything in-place so fragmentation is a potential issue with any file modification (change one byte in the middle of a file and you get a new record somewhere with one byte in it and a bunch of pointers in the metadata saying "stick this byte here" - though for one byte I'm guessing it would end up in the metadata tree much as ext3 stores small files in their inodes so the one byte would be in ram when the pointer to it is loaded). Rich