SnapRAID File Errors

    • OMV 3.x
    • SnapRAID File Errors

      I'm currently using the SnapRAID diff script nightly. I'm happy to say it seems to be working well so far. Unfortunately I'm finding a few evenings where the morning reports lists a number of "file errors" in the summary. I understand what these are from - potential files being altered, modified, etc during the Sync job.

      What I'm trying to do is narrow down what those files are? I've looked through the output, but not been successful in finding anything indicating what files had the error. Is there a way to identify what these were? I'm hoping to find what perhaps I need an exclude rule for.
    • I'd also like to know, relative to the include/exclude, if I'm using MergerFS for pooling - do I need to create this rule for EACH disk in the pool?

      Ex:
      Disk1, Disk2, Disk3 are all part of a pool called Storage1. Disk 4 is my Parity.
      If I want to ignore /directory-on-root/ - do I need to create this exclude rule for Disk1, /directory-on-root/, exclude -- Disk2, /directory-on-root/, exclude -- Disk3, /directory-on-root/, exclude?
      Or if I do need to create this rule on all 3 disks, can I instead just create 1 rule for the pool? Storage1, /directory-on-root/, exclude?
    • 1activegeek wrote:

      do I need to create this rule for EACH disk in the pool?
      Yes but not parity drives. Don't use the pool for anything in snapraid.
      omv 4.0.14 arrakis | 64 bit | 4.13 backports kernel | omvextrasorg 4.1.1
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      Please don't PM for support... Too many PMs!
    • ryecoaaron wrote:

      Yes but not parity drives. Don't use the pool for anything in snapraid.
      Ok, thats what I was thinking - just wanted to be sure.

      Anybody with ideas on where I can find the file error culprits? I'm really hoping to understand this as it's the last thing bugging me with my SnapRAID setup currently. I think it might have been a log folder that was being written to from my pesky docker containers, but I'm not 100% sure and I'd like to nip that part in the but.