| 1 |
On 12/23/2014 09:16 PM, Matthew Thode wrote: |
| 2 |
> I like this (and it has been a long time coming). What format are we |
| 3 |
> going to store the metadata of the use flag combinations and the rest? |
| 4 |
|
| 5 |
The current approach is to store the data in an xpak segment that is |
| 6 |
appended to the end of the tbz2 file. The $PKGDIR/Packages files serves |
| 7 |
as a cache for the essential parts of the xpak data that are used in |
| 8 |
dependency calculations. |
| 9 |
|
| 10 |
> I guess that's already stored since portage knows not to use binpkgs if |
| 11 |
> those change. |
| 12 |
> |
| 13 |
> Also, would this change be a good time to change to store that metadata |
| 14 |
> externally? |
| 15 |
|
| 16 |
That's why we have the $PKGDIR/Packages cache, which is validated using |
| 17 |
stat.st_size and stat.st_mtime |
| 18 |
|
| 19 |
> Running portage over NFS with binpkgs takes forever, I |
| 20 |
|
| 21 |
It's probably all of the readdir and stat calls. If we simply assumed |
| 22 |
that $PKGDIR/Packages was valid, we could eliminate the readdir and stat |
| 23 |
calls. Binhost clients operate under this assumption. |
| 24 |
|
| 25 |
> don't think a binhost makes it faster either. If there were some way to |
| 26 |
> get all the info for the binpkgs into one file (so it could be run on |
| 27 |
> cron or something), this could mean that I'd only have to do one file |
| 28 |
> request for all that metadata and would be much quicker than inspecting |
| 29 |
> all those files. |
| 30 |
|
| 31 |
That's what $PKGDIR/Packages is. |
| 32 |
-- |
| 33 |
Thanks, |
| 34 |
Zac |
Archives