What happens if two separate bitbake invocations both simultaneously
attempt to download the same file?
--rich
On 2/22/12 15:41 , Christopher Larson wrote:
I share it as well. I don't see locks being a big issue for most
things, as the worst case is a re-download, not use of a corrupt or
incomplete file, due to the completion stamps.
--
Christopher Larson
On Wednesday, February 22, 2012 at 4:39 PM, Tom King wrote:
I have a single downloads directory with symlinks for every target
build I have to that directory. As long as I have the source already
in there I don't fetch it again
Tom
On Wed, Feb 22, 2012 at 1:33 PM, Rich Pixley <[email protected]
<mailto:[email protected]>> wrote:
Is it reasonable to expect to share DL_DIR between multiple builds?
That is, are downloads properly locked so that multiple concurrent
downloads of the same file won't collide? And if so, are they NFS
safe locks?
Or must each build download it's own copies of every component?
I ask because our, (Palm), branch has been, but it's a bit of a
nuisance to pick a suitable locking mechanism that is both
functional and performant.
* Flock/lockf aren't reliably supported in heterogeneous environments.
* The old lockfiles don't work over NFS. Lock directories
apparently do, but trying to clean these up after interruptions
or failures is a losing battle so if we do use these, we end up
with orphan locks periodically.
* With NFS as a possibility, we can't assume any kernel local IPC
mechanism, so sysV ipc is out.
* It seems like a pretty huge overhead to try to create any sort
of zeroconf overhead.
Our solution so far has been to use NFS lock directories for
multiple machine builds and flock/lockf for single machine builds.
This mostly works, though it's not ideal, and it's significantly
faster than downloading/copying all of the component source multiple
times even over local mirrors.
--rich
_______________________________________________
Openembedded-core mailing list
[email protected]
<mailto:[email protected]>
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
[email protected]
<mailto:[email protected]>
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
