JorgeB

Yes, but if you were also getting errors with Windows it's likely a device problem.

Very strange then, I never seen that before and I've been using snapshots for years, also don't remember any bug related to that on the mailing list, please report if rebooting fixes that, though if it does stop/start the array should accomplish the same.

I'm also using the beta and would think the most likely is everything is working correctly, just some mistake or confusion, also Krusader showing wrong used space is likely a Krusader issue, I don't see if btrfs isn't freeing the space how Krusader could calculate that, please try this: btrfs sub create /mnt/disk4/test fallocate -l 50G /mnt/disk4/test/file Wait a couple of secs and confirm used space changed by 50G, then: btrfs sub snap -r /mnt/disk4/test /mnt/disk4/test/snap rm /mnt/disk4/test/file Now delete the snapshot and used space should go down by 50G after 30 seconds or so. btrfs sub del /mnt/disk4/test/snap After don't forget to delete test subvolume: btrfs sub del /mnt/disk4/test

Just used my test server for a quick test and using an encrypted filesystem the space was also recovered immediately (it took a few seconds like it usually does) after deleting a snapshot, so appears to not be that.

You can try the invalid slot command, but since it looks like you started the array twice with a different config parity won't be 100% in sync, so some corruption is expected, if you're using xfs it should be recoverable with small to none data loss, before posting the instructions I need to know what Unraid release you're using, also confirm that you only have one parity disk and the number of the disk you want to rebuild.

Syslog starts over after every reboot, you can try this and then post that syslog.

Did you set the correct "power supply idle control" option as described here? If yes try disabling c-states completely.

That suggests it's restoring to an invalid path, e.g. created a folder called /mnt/disk1/Restore and are trying to restore to /mnt/disk1/restore

Try this and post that syslog after it crashes.

Don't forget that Unraid uses independent filesystem for each device, so if you want to do that to a share that spans multiple disks you have to snapshot all disks, not the share.

https://forum.openmediavault.org/index.php?thread/7331-guide-windows-previous-versions-and-samba-btrfs-atomic-cow-volume-shadow-copy/ These instructions are not for Unraid but the principle is the same, samba options can be added on Settings -> SMB -> SMB extras

Looks like a controller issue. make sure it's well seated and sufficiently cooled, you should also upgrade it to latest firmware (20.00.07.00), and can also try a different slot if available.

I don't use encryption, wonder if that can make a difference, see if rebooting really reclaims the space, if yes my guess is that it's related to luks.

Yes, that's it.

Assuming you mean to cache, because the cache floor is set to 10TB.

Sorry, no idea, try booting in safe mode just to make sure it's not plugin related.

Changed Priority to Other

This is likely a general support issue, basically you'd need to start your services one at a time to try and find the culprit.

I never saw that, and I delete snapshots daily. Post the output of: btrfs sub list /mnt/disk# and btrfs fi usage -T /mnt/disk# # is the number of the actual disk.

Don't overclock the RAM, see here: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=819173

Just delete or comment that line.

In that case space is correctly reported, and like mentioned snapshots are immediatly deleted and free space reclaimed, so that's not your problem.

This is normal with btrfs, it allocates 1GB chunks as need, both for data and metadata, this is not a problem, in fact the opposite can be, if the filesystem is fully allocated when it shouldn't be.

Try this: https://forums.unraid.net/bug-reports/prereleases/unraid-os-version-690-beta25-available-r990/?do=findComment&comment=10090