JorgeB

Diags during the check might give some clues.

Disk2 looks mostly OK for now, keep monitoring, you can acknowledge current SMART attribute on the dashboard, parity looks fine, most likely a controller problem, avoid using the Marvell controller on those boards, it's a known issue, use the Intel ports only.

You'll need to reformat to 512 Bytes, Unraid only supports 512 or 4K, same as FreeNAS btw. Recommend LSI based expanders, like the Intel RES2SV240 or RES2CV360, or if buying a chassis with expander any Supermicro with a SAS2/SAS3 expander.

Also files will not be moved due to split level in use and full disks, e.g.: Jul 23 03:40:44 Tower move: move_object: /mnt/cache/Videos/Home video/dashcam/twila/twila-176/Movie/2020_0502_081113_102F.gpx No space left on device

Start here, also note that you have both DIMMs installed on the same channel, they should be on different channels.

This sometimes happen with flash drives, small corruptions occur.

Did you by any change save the diagnostics before rebooting?

Sorry to reply to this locked thread but this was just posted on the btrfs mailing list, you can probably also see it in the df source code but just in case it helps: https://lore.kernel.org/linux-btrfs/[email protected]/T/#t Forgot to mention, as it currently is is we already knew used space on the GUI is not correct for any raid5/6 pool, but it was reported recently in the forum that a 3 device raid1 pool also reports the used space incorrectly, possibly the same for any odd number raid 1 pools, and df shows correct, though both report free space incorrectly, but that part I would think it's likely to be fixed by btrfs in the future.

It might, if it doesn't backup current flash, recreate it from scratch and restore the config folder from the backup.

Try recreating the flash drive.

Changed Status to Closed Changed Priority to Other

Iotop is not part of Unraid, also it works for me with beta25, you likely have a missing dependency, try reinstalling python 2.7 from nerdpack, if you still have issues after that best bet is the nerdpack support thread.

Are you sure the problem in on Unraid side, i.e. have you tried with different source computers?

Yes.

WD60EZAZ it's SMR, and while they generally perform OK with Unraid when writting sequentially you might be hitting the SMR wall, if the rebuild starts fast and it slows down after a few minutes it's likely that.

Then you likely have a hardware problem.

This means there were lost writes sometime in the past and it's usually a fatal error, you need to re-format the cache, if there's important data here are some recovery options, btrfs restore is likely the best for this. P.S. next time please create your own thread since it's unrelated to the OP.

There have been some reports of issues with non QVL RAM, does it run stable with the QVL kit only?

btrfs docker image or vdisks on a btrfs filesystem can and usually does have a very high write amplification, but a btrfs docker image on a xfs filesystem should not be a problem, recently released v6.9-beta25 also mostly fixes this problem for btrfs filesystems, though btrfs will always have more writes than xfs due to being a COW filesystem.

Yes, docker image is still btrfs, but it shouldn't case high writes on a xfs filesystem, though if you want the latest beta allows xfs for the docker image.

That's the docker image, if you have cache you can move it there.

Doen't make much sense, it certainly isn't a general problem, don't remember ever seeing before, might be hardware related, can you try booting Unraid on a different PC?

That shouldn't happen, it just disables the power states.

This is a very strange issue, there are errors even during boot, before any plugins are loaded, if you can disable that NIC and try an ad-don one, you can also try latest beta which is currently more verbose with SMB errors.

You can still rebuild one at a time, but obviously data will only be available as you do it.