JorgeB

And it should do it, I could never reproduce the problem to create a bug report, but this has happened to multiple users, so maybe is just happens with some specific configuration or they are doing something different during the procedure.

Nothing is jumping out to me, just some previous unrelated read errors with the docker image and some log spam, since it's GUI related maybe @bonienlwill have an idea.

IIRC it's "scan user shares"

Just to be clear, you mean it was used to replace a disable data disk, correct?

For some yet unknown reason the parity swap doesn't sync the new parity section for some users, so millions of errors are found on the next sync, just run another check and if no more errors you're fine, unfortunatly diags don't show the parity swap, I'm still trying to find out why this happens to some, I could never reproduce it.

Start in safe mode, if OK, uninstall all plugins and start adding back one by one until you find the culprit. P.S.: I remember Dynamix Cache Directories could have such a repeating spike with certain settings, don't remember what the actual process was.

Upgrade to beta22

Starting the array in maintenance mode won't auto-start the initial parity sync, you need to press the "Sync" button next to array start/stop buttons, or better yet, stop the array and re-start it in normal mode, parity sync will auto-start.

Converting to different profiles doesn't delete data but it's always recommended to backup anything important before starting.

It's a known issue, I already made a request for this to be corrected, for now you need to subtract parity size from the total free space displayed, it's why I'm still using UD for my pools since I have multiple raid 5 pools most with different disks sizes and it's not practical to always been doing mental calculations. That's another known issue, I also reported the same before.

Cache device is still dropping offline: Jun 27 05:14:26 Tower kernel: ata3: link is slow to respond, please be patient (ready=0) Jun 27 05:14:31 Tower kernel: ata3: COMRESET failed (errno=-16) Jun 27 05:14:31 Tower kernel: ata3: hard resetting link Jun 27 05:14:37 Tower kernel: ata3: link is slow to respond, please be patient (ready=0) Jun 27 05:14:41 Tower kernel: ata3: COMRESET failed (errno=-16) Jun 27 05:14:41 Tower kernel: ata3: hard resetting link Jun 27 05:14:47 Tower kernel: ata3: link is slow to respond, please be patient (ready=0) Jun 27 05:15:16 Tower kernel: ata3: COMRESET failed (errno=-16) Jun 27 05:15:16 Tower kernel: ata3: limiting SATA link speed to 1.5 Gbps Jun 27 05:15:16 Tower kernel: ata3: hard resetting link Jun 27 05:15:21 Tower kernel: ata3: COMRESET failed (errno=-16) Jun 27 05:15:21 Tower kernel: ata3: reset failed, giving up Jun 27 05:15:21 Tower kernel: ata3.00: disabled Jun 27 05:15:21 Tower kernel: ata3: EH complete If you have already replaced the cables like recommended it could be a failing disk.

missed this, you'll need to user user root

Then you have other issues, unfortunately error 12 can mean a lot of different things, take a look here: https://bobcares.com/blog/rsync-error-code-12/

Since it was already re-posted by the OP on the Nvidia thread going to lock this one.

You need to specify the full path, assuming "backup" is the share name it would be "/mnt/user/backup"

Best bet is to use the existing plugin support thread:

That would better asked on the UD support thread, but no Unraid flash drive should ever appear as an unassigned device.

Disk looks healthy, most likely filesystem in not a disk problem. Yes, but first you need to backup any data there, then restore it after the format.

Run it again without -n, and if it asks for it use -L

Only if you have pre-created checksums for all files (or were using btrfs).

No more errors on parity, at least so far, now check filesystem on disk2, after it's fixed and if data looks correct you can then rebuild on top.

Jun 25 23:48:52 HOMESERVER kernel: FAT-fs (sda1): error, fat_free_clusters: deleting FAT entry beyond EOF Jun 25 23:48:52 HOMESERVER kernel: FAT-fs (sda1): Filesystem has been set read-only Try reformatting the flash drive or using a different one.

Not yet, v6.9 should be very similar to 6.8, my tests show very small differences (checks with single parity are a little slower faster, with dual parity a little faster slower) but those are very small differences +/- 5MB/s to 10MB/s and likely just because it's using a different kernel, but basically it will be the same, I would guess that understandably LT is looking at more important issues first, but do hope this will be eventually fixed. Edit: slower/faster corrected, it's the other way around

Also, regular Memtest can still be used if there's an option on the BIOS to disable ECC.

👍 You're welcome.