<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 8, 2020 at 12:02 PM Simon Baatz <<a href="mailto:gmbnomis@gmail.com">gmbnomis@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Jan 07, 2020 at 04:45:54PM -0500, Brian Bouterse wrote:<br>
>    We had two bugs filed recently [0][1] which suggest that when using the<br>
>    default backend for Pulp, i.e. pulpcore.app.models.storage.FileSystem<br>
>    Pulp should not be "moving" files. This is the default behavior Django<br>
>    gives us, and it destroys data when sync'ed from file:/// for example<br>
>    [1].<br>
<br>
I am surprised that file:/// should be supported at all. This means<br>
that a worker process must be able to access basically any file on the<br>
system. Is this covered by the (upcoming?) SELinux policy? I would<br>
expect workers to be more constrained than that. Or do we expect<br>
the user to label files before importing?<br></blockquote><div>The user would need to label the files ahead of time. The use case is that a large amount of content is stored on a hard drive which is mounted on the worker. A lot of setups of Pulp use this as a mass-import method before switching their sync's back to the CDN.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
>    I propose that with 3.1 we fix this bug by switching<br>
>    pulpcore.app.models.storage.FileSystem to leave files in place and<br>
>    either hard-link (same filesystem) or copy (different filesystem).<br>
<br>
We should not use hard links:<br>
<br>
- On systems with sysctl "fs.protected_hardlinks" enabled (Ubuntu, Fedora),<br>
  the files would have to be owned by the pulp user to be able to<br>
  create hard-links at all.<br>
- On systems with SELinux enabled, these hard links will share<br>
  the labels.<br>
- Imported hard links are not protected against modification of the<br>
  original file.<br>
<br>
We could try to reflink the file and fall-back to copy (like "cp<br>
--reflink=auto" does)<br></blockquote><div>Great idea; let me try doing it this way. I'll link to my POC pr when it's up. Feel free also to share one. <br></div></div></div>