Open faan11 opened 1 month ago
Hi @stavros-k thank you for you feedback, i did not know that, i'll try to fix that manually.
As you read in the discussion, this issue is not related to upstream. The upstream fixes permission in the frontend folder. This operation is usually fast on a raspberry pi ( i tried that ), but if you try that on a truenas system, is slow. This slowness will lead the deployment to timeout.
Should you have any more question or doubt, let me know
Thank you again, Kind regard Fabio
As you read in the discussion, this issue is not related to upstream. The upstream fixes permission in the frontend folder. This operation is usually fast on a raspberry pi ( i tried that ), but if you try that on a truenas system, is slow. This slowness will lead the deployment to timeout.
The issue here is not TrueNAS exactly, but any system using overlayFS as a storage driver would have this issue. This is noticeable on systems with HDDs, SSDs are recommended for using apps, at least for the apps dataset.
But I still don't get why we need this change. This will still chown and usermod/groupmod (which also does a chown btw) right before the entrypoint. While this running, the timeout still counts.
I'd be more happy to increase the timeout like we did on NginxProxyManager, instead of overriding entrypoint.
In an ideal scenario paperless would run rootless, or at least would have a env var to skip chown at startup.
The issue here is not TrueNAS exactly, but any system using overlayFS as a storage driver would have this issue. This is noticeable on systems with HDDs, SSDs are recommended for using apps, at least for the apps dataset.
Yes, I'm using only HDDs. I did not thought about it. SSDs are fast but HDD are not that slow.
But I still don't get why we need this change. This will still chown and usermod/groupmod (which also does a chown btw) right before the entrypoint.
Yeah but the workaround only does two chown. The default entry point does a recursive chown for an unknown reason ( confirmed also by https://github.com/paperless-ngx/paperless-ngx/discussions/5086#discussioncomment-8756036 , operation: https://github.com/paperless-ngx/paperless-ngx/blob/ff4203938b954dbe4ea3f64333eeb03795887c55/docker/docker-entrypoint.sh#L13 ). This operation takes more than 6 minutes which is is not reasonable, IMO.
I changed my mind. I think the addition of a new env flag in the upstream application is a proper solution. This environment var disable the usermod behaviour when it is enabled. This does not solve the main issue ( the slowness of a recursive chown ) but at least does not add a patches that depends on the upstream behavior.
What do you think? If it is ok for you, we can close this issue and I'll open a pull request in the upstream.
Thank you again
Il 10 luglio 2024 19:16:17 CEST, Stavros Kois @.***> ha scritto:
As you read in the discussion, this issue is not related to upstream. The upstream fixes permission in the frontend folder. This operation is usually fast on a raspberry pi ( i tried that ), but if you try that on a truenas system, is slow. This slowness will lead the deployment to timeout.
The issue here is not TrueNAS exactly, but any system using overlayFS as a storage driver would have this issue. This is noticeable on systems with HDDs, SSDs are recommended for using apps, at least for the apps dataset.
But I still don't get why we need this change. This will still chown and usermod/groupmod (which also does a chown btw) right before the entrypoint. While this running, the timeout still counts.
I'd be more happy to increase the timeout like we did on NginxProxyManager, instead of overriding entrypoint.
In an ideal scenario paperless would run rootless, or at least would have a env var to skip chown at startup.
-- Reply to this email directly or view it on GitHub: https://github.com/truenas/charts/pull/2640#issuecomment-2221058346 You are receiving this because you authored the thread.
Message ID: @.***>
Adding the env upstream would be ideal yes.
As for the slowness, its "expected" behavior from the overlayFS, because when you manipulate the ephemeral layers of the image, it has to copy every layer on a new mutable layer before modifying which consumes a lot of IO.
Thank you, I was expecting that the final layer ( result of merging all layers ) was partially cached in memory. Do you have any documentation reference for this? It's an interesting topic
Thank you, I was expecting that the final layer ( result of merging all layers ) was partially cached in memory. Do you have any documentation reference for this? It's an interesting topic
Hi,
This merge requests fixs the paperless initialization by avoiding the recursive permission that is quite slow on Truenas Scale. The solution can be found also here: https://github.com/paperless-ngx/paperless-ngx/discussions/5086 This merge requests increases the version from 1.2.43 to 1.2.44