Solved ==> Changing ownership on every restart
in my Cloudron use case, I backup a Cloudron instance with 41 apps (as crypted tgz files) to a different Cloudron instance with the minio app. I've observed in case of minio updates, that this special minio app needs up to 4 hours to get back beeing responsive. Can we put the chown command into a kind of "hot fix" instead of using it on every restart?
Do others have the same issue?
@luckow I don't think it's the
chowncommand that takes time. It's really fast, even on large amounts of files.
I am surprised as well. chown should be quick enough (not 4 hours anyway). Do you get the same performance if you run the command on the server directly? How much data are we talking about (you can do
find . -type f | wc -lin the data directory ) ?
sorry for "lying". it felt like 4 hours. the last update/restart takes only 1h10m
Sep 11 17:08:53 ==> Changing ownership
Sep 11 18:16:21 ==> Starting minio
:/app/data#find . -type f | wc -l
50 minutes later
OK, I have pushed an update now which will chown only if required. It's a bit of hack, but if it causes problems we can fix it in a future update.
I've run the update. It's a little bit faster:
Sep 11 21:58:16 ==> Changing ownership
Sep 11 22:41:17 ==> Starting minio
@luckow maybe it's really long on your machine because it actually has to change the ownership, not just ensure it's correct?
Do you have any kind of unusual setup that could cause this ?
strange, I use a Minio app on Cloudron with about 300GB files (backup from my MacBook) and there are absolutely no issues, after update it's immediate available
@luckow Oh, let me guess maybe it's on a filesystem which is not ext4 and does not actually support permissions! can you do
ls -l /app/data?
@luckow Do you know if the partition is ext4?
taken from https://my.example.org/#/system
/dev/sda4 mounted at /home
This ext4 disk contains: ...