Kilrah

https://www.servethehome.com/lsi-sas-2008-raid-controller-hba-information/ Shows as 5GT/s, so Gen2 in the log

SAS2008 is PCIe2 so if it was listed as Gen3 that'd have been a listing error

That's a PCIe2 card, working as such. Quadro might get downgraded because of it, or you have to check BIOS settings

What cards are we talking of?

Looks like mine is already on 3.0.2, did nothing. Current template already has a secret key variable in the advanced section.

I meant more "see how much data there is, compare to typical drive read speed" but that works too. That was in response to you seeing it used to be fast and now it's slow, if that was both with the same options then either you now have much more data or something's going wrong if it now takes longer for the same amount of data. Don't know of one but you could probably make a script that checks whether rsync succeeded or errored and retries if it errored.

One of your drives keeps disconnecting, seems to be sdk. You didn't post full diagnostics so can't really give more details.

Clearing the secure boot keys was the issue, you don't want to do that.

I would run checksum once or twice a year to verify that the data hasn't been corrupted for some reason, but also in a way that it only shows discrepancies instead of updating so I can verify which side is correct. Would also check how long it should take to read that amount of data and check it takes about the expected time when it runs to hopefully catch a failing drive that's slower than it should.

Probably want to remove --checksum, that means each side will need to read the entirety of each file on both sides every time it runs.

The repo has a rule about it, you may or may not agree with it but it's there and submissions need to follow it. If you don't agree then you don't submit. If you do anyway don't be surprised if you get refused. Even more so when OP demonstrated his lack of care/concern by asking where the rules were and being pointed to them, showing he didn't even bother with the basics.

No, but you should be posting in that app's support thread.

In theory yes but the process is known to commonly lead to low quality, and people to often not take the time to verify and fix that. If someone had to write something themselves they will have had no choice than to put in the effort to write it. When they use AI "just post the output, it saves me time and effort" becomes possible and tempting, and experience shows people often do that. You might not but the fact that people do means that when AI use is obvious there will always be an amount of suspicion and lower trust.

Not enough detail. Show your template

A failure would usually come with other signs, e.g. smart errors, a disk being disabled which would come instantly. Array status is essentially a "summary".

10% in 1 year means you'd still have 9 years left at current usage... Assuming that's what we're seeing, 2.4TBW in a year is nothing.

Check the db container required in the official compose file GitHubimmich/docker/docker-compose.yml at v3.0.3 · immich-app/i...High performance self-hosted photo and video management solution. - immich-app/immich

Fix your VPN config, can't reach the webui until VPN is connected.

Might not be related at all. What's the current destination of the copy? I see you have a 16TB drive and a small 4TB, if something is currently being transferred to the latter it'd be way slower than the 16TB. But a failing drive in general can have highly varying speeds. Regions that do not fault completely might take more effort to read/recover.

Not that I know of, but I've never tested for how things scale with the number of drives/storage locations. I'd expect "fuse/not fuse" has more impact that "fuse with few drives/fuse with more drives".

If they're on exclusive shares no overhead, otherwise there's some regardless of location. If the share is not exclusive fuse always has to look on all drives (both from array and all pools) for where the file actually is/has to be created following the allocation rules.

Not unless you "hack" things a bit, on zfs different shares are separate datasets, so from ZFS' perspective they're entirely separate and moving data between them means rewriting everything. Depends what you're writing, for large files probably not, for small ones definitely. The overhead is mostly on file open. If FUSE is an issue then make only the exclusive share, don't use the stock mover but write your own script to offload to array instead of moving to another share and then use unraid's mover.

You can't just change the drive assigned to the pool, click on the pool name, delete it entirely, then create it again with the new disk. If once that's done and the array is started it asks to format then come back.

Sounds like you're assigning it at the wrong place since that would only show for a drive that's in the array, not in a pool.

That's why selfhsoters is winding down. Why did you even try to submit to a third party repo? Make your own and take responsibility for your app instead of trying to conveniently make it someone else's problem. "Conventional" development provides some implicit trust, if you don't understand what you're doing at least some you're not getting your app working in the first place. With AI-backed development that's all out the window, anyone can get something that "works" but without the author being necessarily capable of reviewing the output, and that has led to countless scandals about serious issues/vulnerabilities in new apps. So with AI-assisted development trust goes out the window too regardless of how much experience you have since your experience probably doesn't encompass everything a full stack app involves these days. You might have 30 years experience in backend dev, but the frontend the AI generated for you can have massive issues you wouldn't recognise even if you "review" it because that's not your field and you essentially have 0 years of experience on that particular subject, and they'll go through. Also don't use AI to respond...