Ustrombase

Thank you both! I have been running restic for months now and just forgot to report back but I agree --ignore-inodes does indeed work here and has made a world of difference!I need to pull the latest stats on this but it hides in the background for the most part.

@itimpijust wanted to follow up here in case you had any additional insight

Anyone?

I am currently using restic to backup about 9TB of data which is my entire array + appdata + cache files. Basically everything under `/mnt/user`. I have been noticing that my backups have taken a gigantic amount of time to backup (14hrs+ with no end in sight). I have this thread going on the restic forums: https://forum.restic.net/t/restic-takes-a-long-time/8409/11 They are leading me to realize that using a fuse-based filesystem is the cause and specifically due to shfs which is painfully slow. I want to understand how does Unraid handle inodes on its mount points? Seems my issue is due to inodes not being stable on any fuse-based filesystem which means every file is seen as "new" and has to be re-scanned.

@miniraidhow has it worked for you?

@PtolemyivDid you ever figure this out? I'm considering switching form this revproxy to another one but before I do wanted to get caught up on the latest fixes if any. I haven't seen anything on his github only that you can kill the PID process that runs on a loop for this. I have a feeling the maintainer has stepped away because I also haven't seen any updates to this container.

Hi I have a lot of backtraces in my logs, I am running latest unraid 6.12.6. Is this a known bug? edith-diagnostics-20240124-1630.zip

So are there any further steps to help identify root cause? I haven't had this issue again but it is frustrating to have this issue seemingly unresolved and perhaps just hibernating. To put it in another way is there a way to do a process of elimination?

Yea well that is just great then...

Ok so I have done 6 passes of memtest with no errors so I officially don't think it's the ram. Any other ideas? I may try to recreate the docker image.

BTW I forgot to mention my server is on atm so I can still navigate to it via webUI

I have done more research on this and RAM is coming up. I did change RAM last month, but I did a memtest recently 1 full pass with 0 issues on the RAM. It is a 64gb so it takes a very long time to complete 1 pass. I could run another memtest to make it run for 2 passes, but I rather see if it is another issue first given the 1 pass of memtest recently.

Hi, I am getting issues with my server. I have a `BTRFS critical (device dm-1): corrupt leaf`. My diagnostics are attached. I researched this and I see a solution is to reformat the drive that is having the issue. I have 2 cache pools 1 for VMS and Docker and the other is for cache. I have my data backed up. However, i'm hoping to seek some help on the root cause. edith-diagnostics-20230725-1511.zip

@itimpiany other thoughts here? I feel I have been able to replicate this using other VMs that are not on the same VLAN as my unRAID server host but everything can ping each other. It's not a routing issue as I have other machines able to connect to my unRAID host and to the VMs. I'm unsure what is going on but it feels like it's something to do with unRAID and how it handles VLANs.

So I made sure all VMs and the unRAID host can ping each other and my firewall rules allow traffic hence why I call out pinging because my firewall rules are set for all traffic tcp and udp