Hi. The hardlink task finished. For the record, this is what I run:
cd /var/lib/copr/public_html/results for i in *; do pushd "$i" && for ii in *; do hardlink -vv "$ii"; done; popd >/dev/null; done
It run for more than two days. :)
As I watched the build most saved space come from: 1) chroot_scan/ - same libsolv and dnf logs for the same build in the same day 2) srpm_build/ - it has the same tar ball for resubmits
FYI we are now at Filesystem Size Used Avail Use% Mounted on /dev/vdc1 7.5T 5.7T 1.9T 76% /var/lib/copr/public_html
On Thursday, September 5, 2019 4:00:20 PM CEST Miroslav Suchý wrote:
Hi. The hardlink task finished. For the record, this is what I run:
cd /var/lib/copr/public_html/results for i in *; do pushd "$i" && for ii in *; do hardlink -vv "$ii"; done; popd >/dev/null; done
It run for more than two days. :)
As I watched the build most saved space come from:
- chroot_scan/ - same libsolv and dnf logs for the same build in the same day
Hm, this is weird. From what I can tell, there should be only 3 (log) files in that directories (or Nx3 files). What exactly is linkable there?
- srpm_build/ - it has the same tar ball for resubmits
Weird as well, there shouldn't be tarballs but source RPMs, and since we don't have reproducible builds - those files shouldn't be linkable.
What I thought will be the major space saving place is the rawhide_to_release forked builds.
FYI we are now at Filesystem Size Used Avail Use% Mounted on /dev/vdc1 7.5T 5.7T 1.9T 76% /var/lib/copr/public_html
Awesome, we have a few months again!
Pavel
-- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
Dne 05. 09. 19 v 17:09 Pavel Raiskup napsal(a):
Hm, this is weird. From what I can tell, there should be only 3 (log) files in that directories (or Nx3 files). What exactly is linkable there?
Hmm, this was just mistake cause by formating of output. My fault.
- srpm_build/ - it has the same tar ball for resubmits
Weird as well, there shouldn't be tarballs but source RPMs, and since we don't have reproducible builds - those files shouldn't be linkable.
# pwd /var/lib/copr/public_html/results/@python/python3.8/srpm-builds [root@copr-be srpm-builds][PROD]# find -name astrometry-data-4206.tar.xz |head ./00953171/astrometry-data-4206.tar.xz ./00955002/astrometry-data-4206.tar.xz ./00953380/astrometry-data-4206.tar.xz ./00963734/astrometry-data-4206.tar.xz ./00951719/astrometry-data-4206.tar.xz ./00951765/astrometry-data-4206.tar.xz ./00951697/astrometry-data-4206.tar.xz ./00951952/astrometry-data-4206.tar.xz ./00951709/astrometry-data-4206.tar.xz ./00952065/astrometry-data-4206.tar.xz
On Friday, September 6, 2019 11:32:21 AM CEST Miroslav Suchý wrote:
Dne 05. 09. 19 v 17:09 Pavel Raiskup napsal(a):
Hm, this is weird. From what I can tell, there should be only 3 (log) files in that directories (or Nx3 files). What exactly is linkable there?
Hmm, this was just mistake cause by formating of output. My fault.
- srpm_build/ - it has the same tar ball for resubmits
Weird as well, there shouldn't be tarballs but source RPMs, and since we don't have reproducible builds - those files shouldn't be linkable.
# pwd /var/lib/copr/public_html/results/@python/python3.8/srpm-builds [root@copr-be srpm-builds][PROD]# find -name astrometry-data-4206.tar.xz |head ./00953171/astrometry-data-4206.tar.xz ./00955002/astrometry-data-4206.tar.xz ./00953380/astrometry-data-4206.tar.xz ./00963734/astrometry-data-4206.tar.xz ./00951719/astrometry-data-4206.tar.xz ./00951765/astrometry-data-4206.tar.xz ./00951697/astrometry-data-4206.tar.xz ./00951952/astrometry-data-4206.tar.xz ./00951709/astrometry-data-4206.tar.xz ./00952065/astrometry-data-4206.tar.xz
Thanks, interesting, from builder-live.log:
RPM build errors: stderr: error: create archive failed on file /var/lib/copr-rpmbuild/resultsm05t6tgz/astrometry-data-4204.tar.xz: cpio: write failed - No space left on device create archive failed on file /var/lib/copr-rpmbuild/resultsm05t6tgz/astrometry-data-4204.tar.xz: cpio: write failed - No space left on device Failed to execute command.
So this is caused by error case, when the tarball is packaged into src.rpm. Hmm, hopefully not very frequent case :-(
Pavel
copr-devel@lists.fedorahosted.org