This is true but it’s nice to have the whole app, data and database in one place, going together, snapshotted together, “backupable” together. It’s slower for sure. That said it can be reasonably fast with a large pool (more disks). With the magic of SSD cache, database reads fly and reads are the majority of the loads in my heads. In the future I would put root on ZFS as well and either do SSD cache or have root on ZFS SSD pool that gets send/recved regularly onto the spinning pool so it’s easy to restore when needed.

Thanks for the pointer. Checked, tried a couple others - they don’t know about it. They have some other non-random DNS records. AFAIK they can absolutely find it if they scan for all domains, but it’ll take forever if the name is randomly-generated and sufficiently long. Someone has to be determined to spend the resources. This doesn’t guard against that but against bots trying to fuck with the service at the port. I could move it to a wildcard though. There’s an overlap with another subdomain (they’re actually sub-subdomains and the first sub is common) but I could move that.

Hm. As far as I know that can only be done if AXFR is enabled (it’s not), if the domain has entered some search engine that has remembered it, through SSL cert that’s not wildcard, or through brute force lookup. Am I missing something?

It’s just an A record pointing to my IP. IP’s updated from my router via the DNS provider API.

Thanks for looking into it. As far as I read they moved to an ORM with 10.11 as a prereq to supporting other db engines. I’m guessing the db connection code would be undergoing major changes when they do that so I wouldn’t rewrite the current implementation. I’d either follow that work and help them get it right or rework the implementation after they’re done. We’ll just suffer through the mean time. 😄

64K is generally small recordsize. For media they recommend 1M. My db was sitting on the default 128K recordsize and perforned fine on 10.10. It doesn’t matter much for reads because ZFS keeps it in RAM and if it gets evicted it goes into SSD cache (l2arc). But for writes the cache wouldn’t help unless I disable sync which risks data loss. I don’t think 10.10 did much writes during lib scan so write perf only mattered when something changed.

Not sure if this is the problem I was hitting with my Home Videos library type. It’s got directories with YouTube videos. I tried re-adding it in 12-rc3, which was released a month after the nightly mentioned in the issue thread. Still couldn’t complete. I ended up re-adding the media as Shows library. Works okay with the directory structure I have.

The write performance was recorded without the problematic library (deleted).

That would be reasonable. I did repeated rescans and only counted subsequent rescans. For me the initial scan after upgrade took a bit more but not hours. Subsequent scans took less. E.g. 20min -> 13min for write-optimized filesystem. So that’s reasonable, although 10.10 was way faster. Library scans are expected to get faster in 13 according to some Github threads I read.

When I had the broken Home Videos library I waited 3 days for the initial scan to complete and it did not. Repeated rescans did not seem to complete although I didn’t wait 3 days for them. I’m not taking into account those scan times. Something was wrong with this library type on 10.11 and/or my media. Worked fine on 10.10.

Do you mean the SSL cert? Yes, that’s wildcard on *.mydomain.com. Then the subdomain is kvtn4ftxfreurdcw7qtr21mcywxaqqm.mydomain.com.

I came up with a funny strategy I use to lock it down a bit. What’s exposed to the internet for me is Apache2 reverse proxy. The proxy is locked down to reject all connections EXCEPT for the ones coming from a special subdomain which is something like a 64-character long random string. This prevents pretty any unwanted connections. Obviously the special subdomain must remain as secret as a shared password among the Jellyfin users. It works for trusted users.

What I want ideally is an “authenticated firewall.” OpenWrt rejecting all connections on the open port except for an allowlist of IPs. Then there must be a system where users can authenticate and their IP is added to the allowlist. I haven’t found an off-the-shelf solution like this but I’ll make it some day. Too bad I figured this random string subdomain trick cause it seems good enough for now. :D

600MB. Would that require changes to Jellyfin? They’re on the path to introducing Postgres support.

Complications, yes!

With great power come great … uuh … :D

Also the meme is just bait so you read abt the problem and see if you need to solve it for your setup.

Immich

I got 5 users, over 1TB photos and videos, continuous syncing from Android, AI search, OCR search, you name it, all works great. The only thing at that size is that it needs SSD storage or SSD caching. I got ZFS pool with SSD cache and it’s blazing fast. On disks alone, things are a bit more difficult.

Folks who’ve used Linkwarden and archivebox, which do you prefer? Is one a superset of the other?

This, make a partition thats a few gigs smaller than the drive, add the partitions to the storage pool instead of the raw drives.

Don’t think about drives in terms of reliability. Consider them a consumable in your storage system. The storage system should insulate you from the exact drives. Run a ZFS mirror or RAIDz2. Swap drives when they fail. The exact brand and model shouldn’t matter.

As always the social infrastructure (community, user base) is much more important for the success and use value of a piece of software than the exact technology used to make it (lang, framework, helper tools).

The upgrade was pretty trivial from 2.7.5. Minimal changes in the docker compose file if your was up-to-date on 2.7.5. Mostly version changes. No changes needed to .env other than going to v3.

Ahahaha, nice. Loosely reminds me of how we looked at implementing share-to-app (when that was a novel thing) in a mobile OS circa 2011 and we looked at how iOS did it. It was a list of hardcoded targets - Facebook, Twitter. No pluggability no nothing. Our product team was like - if no pluggability is good enough for Apple, it’s good enough for us!