Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Centralise thumbnail store and make the location configurable #28939

Closed
mmattel opened this issue Sep 7, 2017 · 9 comments
Closed

Comments

@mmattel
Copy link
Contributor

mmattel commented Sep 7, 2017

Thumbnails are currently created and stored for each user
This has some negative impacts like:

  • very high space consumption due to duplicates
  • deleting a mount creates orphan thumbs and database entries

Example 20k pictures can create up to 3GB of thumbs.
Sharing the picture store with 100 people creates 300GB of space consumption
If you remove the picture mount, you have 300GB filespace as file and database orphans

This FR is about to centralize the thumbnail store and make the location configurable

Existing issues/Feature Requests I found related were:

#25770 [Feature Request] adding column "ref_storage" in table oc_filecache
#25213 make thumbnail, trashbin and version paths configurable
#22058 (comment) Primary storage - object store and encryption

Note: could be done in steps.

@PVince81 PVince81 added this to the backlog milestone Sep 9, 2017
@PVince81
Copy link
Contributor

PVince81 commented Sep 9, 2017

Had a discussion with @butonic for adding a new "target_fileid" column in oc_filecache for future symlink support and maybe pointing directly to target storages for mounts. If we had such column, it could also be used to achieve the purpose of the "ref_storage" you suggested.

For encryption, I think currently thumbnails aren't encrypted. If one day we encrypt them, then they'd need to be encrypted with the same keys like the original file, share keys, etc, so everyone who has access to the original file also has access to the thumbnail. It might need additional hook listeners in the thumbnail code.

@PVince81
Copy link
Contributor

PVince81 commented Sep 9, 2017

@butonic @DeepDiver1975

@mmattel
Copy link
Contributor Author

mmattel commented Oct 4, 2017

Another use case beside thumbs for pictures would be thumbs for/from audio/video files (eg cover or album art)

@PVince81
Copy link
Contributor

PVince81 commented Oct 9, 2017

There was an older ticket about this feature request: #17186

@PVince81
Copy link
Contributor

linking another ticket with more discussions #10808

@PVince81
Copy link
Contributor

another one. #17186

@PVince81
Copy link
Contributor

Linking to duplicate: #19548

@mmattel
Copy link
Contributor Author

mmattel commented Feb 16, 2018

As user_x which has admin status, I had historically all my private mounts under admin and not under personal settings. I corrected this today by removing all mounts affected from admin and readded them under personal. Because I also have many pictures, I was wondering about the quantity of items rescanned.

+---------+-------+--------------+
| Folders | Files | Elapsed time |
+---------+-------+--------------+
| 14117   | 93859 | 00:08:16     |
+---------+-------+--------------+

Remembering about this issue here, I deleted manually the orphaned thumbs for user_x and rerun scanning...

+---------+-------+--------------+
| Folders | Files | Elapsed time |
+---------+-------+--------------+
| 3792    | 66132 | 00:05:36     |
+---------+-------+--------------+

The difference was 4.2G in:

+----------+-------+
| Folders  | Files |
+----------+-------+
| 10325    | 27727 |
+----------+-------+

Thumbnail orphans is really an issue !

@stale
Copy link

stale bot commented Sep 20, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Development

No branches or pull requests

4 participants