snapraid + adding new drive

    • OMV 3.x

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • snapraid + adding new drive

      Hi,
      originally i posted that question on snapraid forum but as there is no activity... I am trying to get some help here. I use omv 3.x, 3 drives as data disks, one as parity. I want to add one more data drive (which already contains data on ext4). Can i add it as a data drive into the current config? It wont remove my data?

      original post
      sourceforge.net/p/snapraid/dis…677233/thread/a79653c6d8/


      thank you
    • okay, looks fine, thank you for prompt reply!

      Now one more question... i added drive as a data drive to snapraid... can i also add it into my UnionFS? At the moment i have one item inside UnionFS which consists of 3 drives that were part of the snapraid, so may I add this new drive with data into it? Wont be there any data loss?

      thank you
    • hi,
      i replaced failing drive but still have multiple errors related to the mergerfs in dmesg...

      [44459.406162] EXT4-fs error (device sdd1): htree_dirblock_to_tree:990: inode #157287807: block 629154085: comm mergerfs: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=4294967295, rec_len=65535, name_len=255
      [44459.443936] EXT4-fs error (device sdd1): htree_dirblock_to_tree:990: inode #157287807: block 629154085: comm mergerfs: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=4294967295, rec_len=65535, name_len=255


      these kind of errors are popping up on drive.. even based on the smartctl it looks 100% ok and i unmounted drive, executed fsck on it, mounted it back... but errors are still popping ...

      any idea how to fix that issue.. i am desperate...thanks
    • There isn't much for me to add to the previous conversation. The error is not due to writes (directly). It's a reading of directory info issue (as the error indicates). mergerfs is in the logs because its the proxy for your app's requests. mergerfs is just a proxy. It runs in userspace like any other user software. It's not the cause of the error. It's only triggering it. mergerfs would have to write directly to the device, which it does not, for it to screw up the filesystem data structures itself.

      Look at the error: rec_len % 4 != 0 - offset=0(0), inode=4294967295, rec_len=65535, name_len=255

      The inode, rec_len, and name_len are all maxed out values. All 0xFF. The rec_len is 4 vs the expected 0. I don't know what the defaults are for those variables (I'd imagine 0) but they aren't just random data left over of some directory entry that became corrupted. This looks like it was explicitly set / overwritten.

      As I mentioned in my email this is either 1) a bug with ext4. Try a different kernel or different filesystem. 2) The CPU is faulty. 3) The RAM is faulty. 4) The drive is faulty. 5) something is going around corrupting the drive.

      The only time users have had those kinds of errors were as a result of the above situations.
    • lenovomi wrote:

      @gderf its Linux openmediavault 4.9.61-odroidxu4
      Is it safe to upgrade to 4x? can i do it somehow from gui? configuration smb/nfs will remain?
      I had no problems upgrading from OMV 3.x to 4.x on AMD64. But I followed the upgrade procedure exactly, including removing unsupported plugins and having a known to be restorable backup. I don't think you can upgrade in the GUI, I used the shell.
      --
      Google is your friend and Bob's your uncle!

      OMV 4.x - ASRock Rack C2550D4I - 16GB ECC - Silverstone DS380
    • will try, thanks, got diff error today after i run fsck:


      [ 9102.609111] EXT4-fs error (device sdd1): htree_dirblock_to_tree:990: inode #150994945: block 603988000: comm mergerfs: bad entry in directory: rec_len % 4 != 0 - offset=0(0), inode=3656225552, rec_len=50358, name_len=105
      [24517.929619] EXT4-fs warning (device sdd1): dx_probe:751: inode #151259290: comm mergerfs: Unrecognised inode hash code 173
      [24517.929627] EXT4-fs warning (device sdd1): dx_probe:856: inode #151259290: comm mergerfs: Corrupt directory, running e2fsck is recommended
      [24518.219846] EXT4-fs warning (device sdd1): dx_probe:751: inode #151259290: comm mergerfs: Unrecognised inode hash code 173
      [24518.219853] EXT4-fs warning (device sdd1): dx_probe:856: inode #151259290: comm mergerfs: Corrupt directory, running e2fsck is recommended
      [24518.219970] EXT4-fs warning (device sdd1): dx_probe:751: inode #151259290: comm mergerfs: Unrecognised inode hash code 173
      [24518.219976] EXT4-fs warning (device sdd1): dx_probe:856: inode #151259290: comm mergerfs: Corrupt directory, running e2fsck is recommended
      [24518.220451] EXT4-fs warning (device sdd1): dx_probe:751: inode #151259290: comm mergerfs: Unrecognised inode hash code 173
      [24518.220457] EXT4-fs warning (device sdd1): dx_probe:856: inode #151259290: comm mergerfs: Corrupt directory, running e2fsck is recommended
      [24518.220555] EXT4-fs warning (device sdd1): dx_probe:751: inode #151259290: comm mergerfs: Unrecognised inode hash code 173
      [24518.220561] EXT4-fs warning (device sdd1): dx_probe:856: inode #151259290: comm mergerfs: Corrupt directory, running e2fsck is recommended