Mailing List Archive

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

lnxg33k wrote:
> I added the metadata/some-cat to the rsync_exclude list by prefacing
> every entry with an '*'. Vastly increased the 2nd phase of sync'ing and
> cleared up some storage. I gather that the the cached files end up in
*laughs*

> "/var/cache/edb/dep/usr/portage/". Would purging the rsync_exclude
> entries here cause any problems? I'm guessing that `emerge -S` searches
> would be faster as there are less entries to check. There's also the
> storage issue as well. Thanks

Maybe the benifit is good for you. Those metadata directories in the
tree are important because generating portage metadata is costly in
terms of time. Thats WHY we do it.

When you exclude those directories ( or all of metadata/ ) you are
merely moving the cache time from emerge --sync to emerge <blar>.
Portage will notice the stale cache and regenerate the metadata on the
fly. As noted earlier, this generation is SLOW. Maybe you notice,
maybe you do not. It really depends on whether the queries you run
against portage hit the areas that lack on-disk metadata.

For extra fun, try rm -rf /var/cache/edb/dep/usr, then an emerge --regen
and tell me it's fast ;)

As for the emerge -S bit, it won't be any faster. It still iterates
over the whole tree, and once again, portage will generate the metadata
locally = slower. Use another tool, ( eix,esearch ) they are better for
this IMHO. Sorry it doesn't come all built into one tool, we are
working on it.

Alec Warner (antarus)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQ9bcEmzglR5RwbyYAQI3eg//dwNY+bKhHf1F4qeD2tf6dlHcHXZUQbNt
TLvI+w141ld58Dnwt5GI7BZQKo/WqFr+cBzuN0bbZJNO22dPNbSCEot+u2q0Q7l+
/1pb6qtWb+M2Vm5ruU6jCb/i+IVTji6eMu58GEUx4cdzP0ovUILXjEq8/JFynaT8
v3AMMLORxOMSgcnq0iW4ScGaSUdwG3eKiS0wF8WkPvLcS0nI2UgVlyyPEuskx2Gl
PW5SPZoLT2HHdNdsgh3wZ7WWkUQbpwVpFS0RiVjeMmHHDJOLRvYn0iPcNsPSeXWu
wkCkrKlJyNTMA4HcBFjDo7MmM0wzHrktjOLsOhCULmnXGBXWNrpEEQ9KJxNr49sn
JjiZBuxY+K0gAa6QMGF9REksR1Eoi6xJvAZjpd6MEEBft9ZSCKmeT5DXGmyjAsVC
eW9LnL3JasaZXmz85UXTb5D6aUycX4mvP73X/iCgd/B1mVBUpa/CyCoQvDn7kGsk
ZQZgXcYbb8ikwnwFrnvwetl7Brti1xEEtsIvgYLzQG9OOQCbd1ZE+4sC5HDEgT6o
jrWlOqyXj2e8dxHLSGKz3BARLm9xKLzZfl7kq5n66bYc43BEy4srjvscjL8dw9fr
W0YiUvsWjWK5GE/i/U1HN10QLuRqkrkHQXGkAo5V7ZtaiqDXf95N0pzL6i+p1ViP
l1eWVpQuMuU=
=HQCQ
-----END PGP SIGNATURE-----
--
gentoo-performance@gentoo.org mailing list

Alec Warner wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> lnxg33k wrote:
>> I added the metadata/some-cat to the rsync_exclude list by prefacing
>> every entry with an '*'. Vastly increased the 2nd phase of sync'ing and
>> cleared up some storage. I gather that the the cached files end up in
> *laughs*
>
>> "/var/cache/edb/dep/usr/portage/". Would purging the rsync_exclude
>> entries here cause any problems? I'm guessing that `emerge -S` searches
>> would be faster as there are less entries to check. There's also the
>> storage issue as well. Thanks
>
> Maybe the benifit is good for you. Those metadata directories in the
> tree are important because generating portage metadata is costly in
> terms of time. Thats WHY we do it.
>
> When you exclude those directories ( or all of metadata/ ) you are
> merely moving the cache time from emerge --sync to emerge <blar>.
> Portage will notice the stale cache and regenerate the metadata on the
> fly. As noted earlier, this generation is SLOW. Maybe you notice,
> maybe you do not. It really depends on whether the queries you run
> against portage hit the areas that lack on-disk metadata.
>
> For extra fun, try rm -rf /var/cache/edb/dep/usr, then an emerge --regen
> and tell me it's fast ;)
>
> As for the emerge -S bit, it won't be any faster. It still iterates
> over the whole tree, and once again, portage will generate the metadata
> locally = slower. Use another tool, ( eix,esearch ) they are better for
> this IMHO. Sorry it doesn't come all built into one tool, we are
> working on it.
>
> Alec Warner (antarus)
<snip>

Heh heh. I should hit the books or something. ;) Actually, I rarely search and
haven't emerged anything so I haven't had the chance to see the effects of my
"insight". I keep thinking "less files = faster 'x' because nothing to do". I
had eix installed until today when I realized I never searched. Anyway, thanks
once again for the err in thinking.
--
gentoo-performance@gentoo.org mailing list