[Feature] Separate thumbs storage location by quality

[mmomjian]

I have searched the existing feature requests, both open and closed, to make sure this is not a duplicate request.

• Yes

The feature

We now have 3 qualities of thumbs:

• thumbnail
• preview
• fullsize

Users may want to use flash storage for some but not all of these files. For example, on my system, the thumbnail WEBPs take 3 GB, while the preview JPEGs take 60 GB. Moving the thumbnails to an SSD would greatly improve the timeline experience.

Proposed solution: migrate thumbs to 3 subfolders:

• thumbs/thumbnail/<user UUIDs>
• thumbs/preview/<user UUIDs>
• thumbs/fullsize/<user UUIDs>

In this way users can mount varying storage to the subfolders and mix flash and HDD storage. This shouldn't be a breaking change, and we can use the Storage Migration job.

Platform

• Server
• Web
• Mobile

[jzavalaneri]

This is great!

I would love for this to be implemented to allow my unsaid server to upload thumbnails much quicker to the mobile app while I'm not home.

[NicholasFlamy]

#18640

[joojoooo]

This PR doesn't separate preview and fullsize thumbs 👎

[mmomjian]

There has been extensive discussion on discord. at this time the sizes are not stable enough to split beyond thumbs

[NicholasFlamy]

This PR doesn't separate preview and fullsize thumbs 👎

Yes, that is on purpose. First, I'm not sure why you'd want preview and fullsize separated. But ignoring that point, it's actually because the devs haven't decided on finalizing those items.

[thilo]

I worked on a similar PR, I wonder regardless the sizes if you are open to split assets by serving requirements?

Concrete use case:

I have a server that mounts a big cheap CIFS volume to host the original files, there a bit of latency and slower access is okay as I only request a few at a time. The preview folder stays on main machines disk to serve all the little thumbs fast and low latency. I now run into the problem that I have to resize the fast ssd machine drive faster than the CIFS mount, because thumbs also includes previews, which are significantly bigger. Meaning I have to spend more money on faster storage. At the same time they don't have the same serving requirements, I could easily put them on the CIFS if they are put in a different folder.

My proposal split files along that line while staying open for variable sizes in the future.
e.g. /thumbs (everything that needs low latency fast access) /previews (everything that can have a bit more latency as only a few are fetches at a time).

I'm happy to do a PR.