On Sat, Nov 26, 2011 at 7:59 AM, Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote: > On Sat, 26 Nov 2011 18:20:27 +0530 > Nirbheek Chauhan <nirbh...@gentoo.org> 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
