JorgeB

Any vdisk that doesn't discard freed space will keep growing.

Yes. No.

You can do the parity swap, one of the first steps is to disable the disk you want to replace, since it's not yet disabled, after you do that you can remove that disk and connect the new parity.

There are still macvlan call traces, also the server is constantly running out of RAM.

In the first screenshot there's still plenty of space, but if the free space keeps getting lower without writing new files it's usually lack of discard on vdisks, see here for Windows VMs: https://forums.unraid.net/topic/51703-vm-faq/?do=findComment&comment=557606

Disk dropped offline so there's no SMART report, check replace cables and post new diags.

SMART for parity is showing some issues, but current problem look more power/connection related, power down the server, check/replace cables on parity and then try this, but note that it will only work if parity is still valid: -Tools -> New Config -> Retain current configuration: All -> Apply -Check all assignments and assign any missing disk(s) if needed -IMPORTANT - Check both "parity is already valid" and "maintenance mode" and start the array (note that the GUI will still show that data on parity disk(s) will be overwritten, this is normal as it doesn't account for the checkbox, but it won't be as long as it's checked) -Stop array -Unassign disk1 -Start array (in normal mode now), ideally the emulated disk will now mount and contents look correct, if it doesn't you should run a filesystem check on the emulated disk -If the emulated disk mounts and contents look correct stop the array -Re-assign disk1 to rebuild and start array to begin. Keep old disk1 intact for now in case it's needed.

If parity swap is the adequate procedure for what you need you can disconnect the disabled disk.

It's not, but ddrescue might still be able to recover most data. You can, though ddrescue might be have a better chance of recovering more data, especially if the disk keeps getting worse with access. If the disk is really failing like it looks that won't work because there will be read errors on disk1, so parity won't be able to sync correctly.

Changed Priority to Other

To get the array back to running you can do a new config (with or without parity), new disk1 will need to be formatted, you can then try ddrescue on old disk1.

v6.9.2 has some known issues with spin down, suggest going back to v6.9.1 or trying v6.10-rc2.

There's a chance of recovery but only if you use a deleted file recovery util, like UFS explorer or similar. Docker image can easily be recreated.

Forgot to mention, cache filesystem is corrupt, for btrfs is best to backup and reformat, I see that you're running Ryzen with overclocked RAM, that's a known cause of data corruption, see here and adjust RAM speeds accordingly.

You formatted disk4, formatting is never part of s rebuild, there's a warning about it: When you have an unmountable this the correct thing to do is to check filesystem.

This.

Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enable, top right)

Marvell controllers are not recommended, especially connected to a SATA port multiplier, avoid both.

That means it's using RAID firmware, ideally you'd crossflash to IT mode, there's a thread about that, but it's more complicated than just an update, and it can't be done inside Unraid, alternatively update it with RAID firmware to 20.00.07 and see if it helps.

You can try a full disk write, it might help or not.

I would suggest upgrading to v6.10-rc, it includes newer xfs-progs, then try repairing the fs again.

Please use the existing plugin support thread:

No, they all will have the same exact capacity, brand/model doesn't matter, except some drives that come from USB enclosures.

Check filesystem on disk1.