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 |