Selfhosted

40347 readers

354 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.

Resources:

selfh.st Newsletter and index of selfhosted software and apps
awesome-selfhosted software
awesome-sysadmin resources
Self-Hosted Podcast from Jupiter Broadcasting

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 1 year ago

MODERATORS

HybridSarcasm@lemmy.world

HybridSarcasm@lemmy.hybridsarcasm.xyz

Splitting Docker between SSD and HDD (lemmy.world)

submitted 5 months ago by Naate@lemmy.world to c/selfhosted@lemmy.world

12 comments fedilink hide all child comments

I'm in the process of planning upgrades for my server, and I'm trying to figure out the "best" drive configuration for Docker. My general understanding would be that the containers should be running from an SSD, and any storage (images, videos, documents) should use a volume on an HDD.

Is it as simple as changing the data-root to point to the SSD, and keep my external volumes on the HDD as defined in my existing compose files? I've already moved data-root once b/c the OverlayFS was chewing up the limited space on the OS drive, so that process isn't daunting.

If there's a better way to configure Docker, I'm open to it, as long as it doesn't require rebuilding everything from scratch.

For reference, the server is running Debian Bookworm on an older i5 3400 with 32GB RAM.

you are viewing a single comment's thread
view the rest of the comments

[–] CameronDev@programming.dev 2 points 5 months ago (1 children)

I5 3470 is old, but its not that bad. Lots of people are homelabing on NUCs which are only very slightly faster. Performance per Watt will be terrible though. (I am on an i7-10710u, and I've yet to run out of steam so far - https://cpu.userbenchmark.com/Compare/Intel-Core-i7-10710U-vs-Intel-Core-i5-3470/m900004vs2771 )

It has VTx/VTd, so should be okay for proxmox, what makes you think it won't work well?

[–] possiblylinux127@lemmy.zip 3 points 5 months ago (1 children)

I had in my head that it didn't have the proper extensions for virtualization.

However, the memory and core count will be a bottleneck with virtualization. Only having 4 cores will make it a hard to delicate resources and the slower ram will mean you could have performance issues. It really depends on what you are doing I suppose. It does have 6mb of cache which will help some.

If you got a i5 6500 with ddr4 memory you would have much better performance.

[–] CameronDev@programming.dev 1 points 5 months ago

4 cores is a bit limiting, but definitely depends on the usage. I only have 1 VM on my NUC, everything else is docker.

I thought all the core processors had VT* extensions, I was using virtualization on my first gen i7. They are very old an inefficient now though.