<div dir="ltr">I filed a bug report and submitted a fix, which will appear in 2.8.1.<div><br></div><div><a href="https://pulp.plan.io/issues/1789">https://pulp.plan.io/issues/1789</a><br></div><div><br></div><div>Michael</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 17, 2016 at 12:53 PM, Michael Hrivnak <span dir="ltr"><<a href="mailto:mhrivnak@redhat.com" target="_blank">mhrivnak@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">This appears to be a regression in 2.7.<div><br></div><div>In 2.6 (and earlier), at the completion of each rpm download, the file would be moved from its temporary location to the permanent location. That means for any given sync, you would never have more files in that temporary location than you did concurrent downloads. Using the default setting of 5 concurrent downloads, that's a maximum of 5 rpms. No problem so far.</div><div><br></div><div>This change turned the "move" into a "copy":</div><div><br></div><div><a href="https://github.com/pulp/pulp_rpm/commit/de1895ede2f24731dcf6f52321beaee6b71c15a4" target="_blank">https://github.com/pulp/pulp_rpm/commit/de1895ede2f24731dcf6f52321beaee6b71c15a4</a><br></div><div><br></div><div>Now all of the rpm files pile up, and they don't get removed until the end of the task. On quick glance, it appears that 2.8 suffers the same problem, although the code has been refactored.</div><div><br></div><div>If you don't mind filing a bug report, it should be an easy fix: likely just adding a delete call after the copy.</div><div><br></div><div><a href="https://pulp.plan.io/projects/pulp_rpm/issues/new" target="_blank">https://pulp.plan.io/projects/pulp_rpm/issues/new</a><br></div><div><br></div><div>Thanks,</div><div>Michael</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 17, 2016 at 11:39 AM, Randy Barlow <span dir="ltr"><<a href="mailto:rbarlow@redhat.com" target="_blank">rbarlow@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wednesday, March 16, 2016 12:23:48 AM EDT Matthew Madey<br>
wrote:<br>
<span>> I think it's failing to remove the files when they are done. Currently<br>
> there are 2G of RPM's in the cache directory, most of them are<br>
0bytes. I'm<br>
> syncing with the RHEL7 repository, and I'm seeing every package in<br>
the<br>
> repository in the cache directory, however, once it had filled /var,<br>
the<br>
> remaining RPM files were 0 bytes. Is there a way to limit to how<br>
much<br>
> content is able to be staged in the cache directory before being<br>
published<br>
> to /var/lib/pulp?<br>
<br>
</span>Hello again Matthew!<br>
<br>
I believe that the sync task downloads all the RPMs into /var/cache/<br>
pulp and then moves them into /var/lib/pulp as a later step. Several of<br>
us developers want to redesign our plugin API to support stream<br>
processing, but in the meantime you will need enough storage in /var/<br>
cache/pulp to support all the bytes for an entire sync. I don't know off<br>
the top of my head how large distro repos are, but I'd say they're<br>
usually on the scale of 10s of GBs.<br>
<div><div><br>
_______________________________________________<br>
Pulp-list mailing list<br>
<a href="mailto:Pulp-list@redhat.com" target="_blank">Pulp-list@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-list" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-list</a><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>