SSD wear concerns
I have the storage template put album photos under a directory with the album name. I created albums after the upload so some photos are in the wrong directories. If i run the migration job, does it wear SSDs by doing double the writes to move the file?
Even if I create the album in advance, the app adds photos to albums separately only after upload, with a separate HTTP request, does this behavior cause other writes too?
Is there a way to upload files directly into an album and correct directory to avoid multiple writes?
20 Replies
:wave: Hey @jojo,
Thanks for reaching out to us. Please carefully read this message and follow the recommended actions. This will help us be more effective in our support effort and leave more time for building Immich :immich:.
References
- Container Logs:
docker compose logs docs
- Container Status: docker ps -a docs
- Reverse Proxy: https://immich.app/docs/administration/reverse-proxy
- Code Formatting https://support.discord.com/hc/en-us/articles/210298617-Markdown-Text-101-Chat-Formatting-Bold-Italic-Underline#h_01GY0DAKGXDEHE263BCAYEGFJA
Checklist
I have...
1. :blue_square: verified I'm on the latest release(note that mobile app releases may take some time).
2. :blue_square: read applicable release notes.
3. :blue_square: reviewed the FAQs for known issues.
4. :blue_square: reviewed Github for known issues.
5. :blue_square: tried accessing Immich via local ip (without a custom reverse proxy).
6. :blue_square: uploaded the relevant information (see below).
7. :blue_square: tried an incognito window, disabled extensions, cleared mobile app cache, logged out and back in, different browsers, etc. as applicable
(an item can be marked as "complete" by reacting with the appropriate number)
Information
In order to be able to effectively help you, we need you to provide clear information to show what the problem is. The exact details needed vary per case, but here is a list of things to consider:
- Your docker-compose.yml and .env files.
- Logs from all the containers and their status (see above).
- All the troubleshooting steps you've tried so far.
- Any recent changes you've made to Immich or your system.
- Details about your system (both software/OS and hardware).
- Details about your storage (filesystems, type of disks, output of commands like fdisk -l and df -h).
- The version of the Immich server, mobile app, and other relevant pieces.
- Any other information that you think might be relevant.
Please paste files and logs with proper code formatting, and especially avoid blurry screenshots.
Without the right information we can't work out what the problem is. Help us help you ;)
If this ticket can be closed you can use the /close command, and re-open it later if needed.You should really stop worrying about this, but it should be a move not a new write
Assuming you have both upload and library in the same docker mount
i don't, library is in a different physical disk. How does uploading to an album work? I used developer console in the browser and I see a separate request to put the uploaded photo in the album, is it stored in the upload folder until the "add to album" is received? Or is it saved in the wrong folder in library and then moved to the correct one after "add to album" is received ?
I would recommend to disable the storage template if moves or re writes aren’t ideal for your system
I'm just asking why the album is not sent together with the photo so it can be put immediately in the correct location, why is it added to an album only later? And how later is too late, since if if I stop the PUT request to /api/albums/ID/assets the uploaded file ends up in the wrong directory, so it's not even waiting for that request
That’s just how it’s designed right now, there’s not really a set reason for it
There’s no concept of “waiting”. If it doesn’t get the album add request it will move it to the default(non album) location when the metadata extraction is complete
if the "add to album" request is delayed, it still gets added to the album but it gets put in the wrong directory
Yes, because the move job ran before the album add came through
The storage template job can be used to migrate all assets to the new proper location
so I should bind upload and library to the same disk? so then it's just a move that doesn't write twice? Can I bind upload to tmpfs (RAM) ? is there any important data that needs to be kept in the upload directory or is it just temporary?
You should put upload and library on the same disk, then all moves should be handled by the FS
You should 100000% not use a tmpfs for upload.
why not?
Because if a file gets uploaded and not moved yet you could lose it??
i thought the file gets added to the database only after it's successfully moved to the library. So if it fails it would just reupload automatically.
Thats not correct
if there is no concept of waiting, does that mean this issue can happen even if I don't "artificially" delay the "add to album" request ?
Asking out of curiosity, what ssd wear concerns do you have for a drive that'll be mainly archival? There should be such limited write operations that this is a non-issue for even cheap drives
Yes. The upload process is not atomic with regard to album ownership
immich doing double the writes, writes shortening SSD lifespan. But as Zeus reassured me, it's moves not copies, so it's just an additional inode write
Would you believe me if I told you storage devices are meant to be used..?
2x write through is minuscule for even a cheap SSD
even so, what's the TBW of your ssd, and what's it's capacity. I bet you can do multiple hundred writes before getting anywhere near the spec of the unit
and for immich, the file will remain on the ssd, not move, not be altered - as it's there for long term storage. So that data will not be rewritten - hence the question about why does it matter?
If you were talking about a service making continuous unnecessary writes, that'd be a different discussion