Gentoo Archives: gentoo-dev

From: Rich Freeman <rich0@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: proj/portage:master commit in: pym/portage/dbapi/
Date: Sat, 26 Nov 2011 13:45:06
Message-Id: CAGfcS_k+jKAxsq9znTp+5_fuWkuzi78=hLpCi+wWA_RLqWkJtw@mail.gmail.com
In Reply to: Re: [gentoo-dev] Re: proj/portage:master commit in: pym/portage/dbapi/ by Ciaran McCreesh
1 On Sat, Nov 26, 2011 at 7:59 AM, Ciaran McCreesh
2 <ciaran.mccreesh@××××××××××.com> wrote:
3 > On Sat, 26 Nov 2011 18:20:27 +0530
4 > Nirbheek Chauhan <nirbheek@g.o> wrote:
5 >> Actually, reading the code it seems that it's about the file merge
6 >> order of a single package. My participation in this entire discussion
7 >> is m00t. Never mind. :p
8 >
9 > ...in which case it's often an awful lot faster to sort by inode, not by
10 > filename. Try it when installing a kernel sources package.
11
12 I can believe it. Btrfs added inode-order directory indexes precisely
13 for this reason. I'd have to look up the details but I think it was
14 designed to return the directories in this order to function calls so
15 that anything that iterates through the tree would get this
16 optimization by default. Of course, if you then resort the list first
17 you lose that. (It also has the ext3 dir_index-style indexes for
18 named file lookups.)
19
20 Oh, on the topic of btrfs, if any emerge operations do file copies,
21 adding --reflink=auto to the cp command will GREATLY improve
22 performance. That does a copy-on-write copy - it behaves like a
23 hard-link as far as time to create goes, but it behaves like a full
24 copy as far as modifications not being shared goes. It also uses
25 almost no additional disk space until the content starts to diverge
26 between the copies. Setting reflink=auto should be safe on non-COW
27 filesystems as it will fall back to a normal copy if the operation
28 isn't supported. It is available in stable coreutils. Some speculate
29 that this option could increase fragmentation (both copies will share
30 extents from the original file, and have some extents of their own),
31 but btrfs doesn't overwrite anything in-place so fragmentation is a
32 potential issue with any file modification (change one byte in the
33 middle of a file and you get a new record somewhere with one byte in
34 it and a bunch of pointers in the metadata saying "stick this byte
35 here" - though for one byte I'm guessing it would end up in the
36 metadata tree much as ext3 stores small files in their inodes so the
37 one byte would be in ram when the pointer to it is loaded).
38
39 Rich

Replies