Project

Profile

Help

Issue #8295

Disc Usage during Repository Sync

Added by wibbit 7 months ago. Updated 22 days ago.

Status:
CLOSED - CURRENTRELEASE
Priority:
Normal
Assignee:
Category:
-
Sprint/Milestone:
Start date:
Due date:
Estimated time:
Severity:
2. Medium
Version:
Platform Release:
OS:
Triaged:
Yes
Groomed:
No
Sprint Candidate:
No
Tags:
Sprint:
Sprint 101
Quarter:
Q2-2021

Description

While performing a repository sync recently I noticed that the WORKING_DIRECTORY was of a much much larger size than I expected.

It is currently assigned 150GB, yet failed to sync 3 repositories (I believe RHEL7 Source, RHEL7 Debug, and possibly RHEL7 Server) due to running out of disk space.

I was of the understanding that the working directory was not intended to hold the entire repository till completion, but only the individual unit's being transferred, on a successful transfer, that would then be ingested and end up as an artefact and stored in the artefact's path.

I believe an additional side affect of this, is that though units have been downloaded cleanly, and I believe could have been converted to an artefact, this has not been done, and a complete re-download is required as evidenced by the fact that on an additional sync the same behaviour occurs.

Maybe this would be the case any way, unless the artefact is converted to content, I'm unsure of those specifics.

sync_disk_usage_change.patch (2.15 KB) sync_disk_usage_change.patch lmjachky, 05/02/2021 01:54 PM

Related issues

Related to Pulp - Issue #8296: Pulp worker directories not cleaned upNEW<a title="Actions" class="icon-only icon-actions js-contextmenu" href="#">Actions</a>
Related to Pulp - Issue #7316: Files are not being deleted from storage when calling the method delete()CLOSED - CURRENTRELEASE<a title="Actions" class="icon-only icon-actions js-contextmenu" href="#">Actions</a>
Related to Pulp - Issue #9000: On-demand downloading fills up /var/run, causing errorsCLOSED - CURRENTRELEASE<a title="Actions" class="icon-only icon-actions js-contextmenu" href="#">Actions</a>
Copied to Pulp - Backport #9103: Backport 8295 "Disc Usage during Repository Sync" to 3.14.zCLOSED - CURRENTRELEASE

<a title="Actions" class="icon-only icon-actions js-contextmenu" href="#">Actions</a>

Associated revisions

Revision fbe2d7f9 View on GitHub
Added by Lubos Mjachky about 2 months ago

Move downloaded files instead of copying them

Before this commit, the condition that checks whether pulp's temporary files are stored within /var/lib/pulp was never met because it looked for files starting with /var/lib/pulp/media (MEDIA_ROOT). MEDIA_ROOT is however no longer pointing to /var/lib/pulp.

closes #8295

History

#1 Updated by dalley 7 months ago

  • Project changed from RPM Support to Pulp

#2 Updated by dalley 7 months ago

  • Related to Issue #8296: Pulp worker directories not cleaned up added

#3 Updated by dalley 7 months ago

  • Related to Issue #7316: Files are not being deleted from storage when calling the method delete() added

#4 Updated by daviddavis 7 months ago

  • Triaged changed from No to Yes

#5 Updated by ttereshc 5 months ago

Just for some context. It might be a pulpcore issue but it also can be pulp_rpm specific because working directory is recreated a lot in pulp_rpm.

#6 Updated by ipanova@redhat.com 5 months ago

  • Sprint set to Sprint 94

#7 Updated by lmjachky 5 months ago

  • Status changed from NEW to ASSIGNED
  • Assignee set to lmjachky

#8 Updated by rchan 5 months ago

  • Sprint changed from Sprint 94 to Sprint 95

#9 Updated by rchan 5 months ago

  • Sprint changed from Sprint 95 to Sprint 96

#10 Updated by lmjachky 5 months ago

I made a couple of experiments and noticed that our pipeline is not really creating artifacts from temporary files along the way during the sync process. This is caused by the parameter minsize (https://github.com/pulp/pulpcore/blob/354383883032277e7a1f7dc7ddf2dc0a5bc40fad/pulpcore/plugin/stages/api.py#L84) that retains the pipeline from saving artifacts unless the queue is filled up (https://github.com/pulp/pulpcore/blob/eda2c890214a76e6f6ffa18cc939d04273b1fa13/pulpcore/plugin/stages/artifact_stages.py#L229).

Furthermore, all the temporary files are being deleted only when the whole sync process ends. Because of the parameter delete in NamedTemporaryFile (https://github.com/pulp/pulpcore/blob/354383883032277e7a1f7dc7ddf2dc0a5bc40fad/pulpcore/download/base.py#L122), we should handle the removal manually by ourselves. The working directory (temporary files stored under a specific task) is cleared as a whole only when the sync process reasonably finishes.

Also, another problem is that in some cases pulp_rpm do not handle the removal of temporary repodata files at all. When I synced from the http://mirrors.sonic.net/epel/playground/8/Everything/x86_64/os/, the downloaded repodata (3.9GB) were not removed even when the sync process successfuly ended. It seemed to me that I never reached this return statement: https://github.com/pulp/pulp_rpm/blob/f14be05d58f06e794676a5222b443cd9d082f031/pulp_rpm/app/tasks/synchronizing.py#L428, weird. Yet, the sync proceeded without failures.

So, I propose to examine some of the default parameters we changed in https://github.com/pulp/pulpcore/pull/440/files and call os.unlink right after we create artifacts. I am attaching some of the advised changes in the description and unassigning myself.

#11 Updated by lmjachky 5 months ago

  • Status changed from ASSIGNED to NEW
  • Assignee deleted (lmjachky)

#12 Updated by rchan 4 months ago

  • Sprint deleted (Sprint 96)
  • Quarter set to Q2-2021

We are putting this one on hold for now since this Sprint was busy, but do plan to work on it this quarter.

#13 Updated by dalley 3 months ago

  • Status changed from NEW to ASSIGNED
  • Assignee set to lmjachky
  • Sprint set to Sprint 99

@Lubos, This is important work and we want to get to this soon (discussed in the 3 month planning meeting), but nobody has had time to pick it up yet. If you could pick it back up when you return next week that would be excellent

#14 Updated by pulpbot 3 months ago

  • Status changed from ASSIGNED to POST

#15 Updated by rchan 3 months ago

  • Sprint changed from Sprint 99 to Sprint 100

#16 Updated by lmjachky 2 months ago

The commit https://github.com/pulp/pulpcore/commit/887dafa189639e310b7bd78ab96adbb188aa5a66 partially resolved the problem. Since it was merged, all temporary directories are properly cleared. Therefore, the statement "in some cases pulp_rpm do not handle the removal of temporary repodata files at all" is not true anymore.

However, the disk space is freed only when a task finishes. So, temporary files are still not being removed gradually through the sync, while the task is running. I am investigating more possibilities of resolving this issue.

#18 Updated by dalley 2 months ago

  • Related to Issue #9000: On-demand downloading fills up /var/run, causing errors added

#19 Updated by rchan 2 months ago

  • Sprint changed from Sprint 100 to Sprint 101

#21 Updated by dalley 2 months ago

  • Sprint/Milestone set to 3.15.0

#22 Updated by dalley 2 months ago

  • Copied to Backport #9103: Backport 8295 "Disc Usage during Repository Sync" to 3.14.z added

#23 Updated by Anonymous about 2 months ago

  • Status changed from POST to MODIFIED

#24 Updated by pulpbot 22 days ago

  • Status changed from MODIFIED to CLOSED - CURRENTRELEASE

Please register to edit this issue

Also available in: Atom PDF