Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Rich Freeman <rich0@g.o>
Subject: Re: Re: proj/portage:master commit in: pym/portage/dbapi/
Date: Sat, 26 Nov 2011 08:44:28 -0500
On Sat, Nov 26, 2011 at 7:59 AM, Ciaran McCreesh
<ciaran.mccreesh@...> wrote:
> On Sat, 26 Nov 2011 18:20:27 +0530
> Nirbheek Chauhan <nirbheek@g.o> 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


Replies:
Re: Re: proj/portage:master commit in: pym/portage/dbapi/
-- Nirbheek Chauhan
Re: Re: proj/portage:master commit in: pym/portage/dbapi/
-- Michał Górny
References:
Re: proj/portage:master commit in: pym/portage/dbapi/
-- Fabian Groffen
Re: Re: proj/portage:master commit in: pym/portage/dbapi/
-- Nirbheek Chauhan
Re: proj/portage:master commit in: pym/portage/dbapi/
-- Nirbheek Chauhan
Re: Re: proj/portage:master commit in: pym/portage/dbapi/
-- Ciaran McCreesh
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Re: proj/portage:master commit in: pym/portage/dbapi/
Next by thread:
Re: Re: proj/portage:master commit in: pym/portage/dbapi/
Previous by date:
Re: RFC: Gentoo News file about GNOME 3.2's unmasking
Next by date:
Re: Re: proj/portage:master commit in: pym/portage/dbapi/


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.