ReadyNAS Ultra 4 "Volume scan found errors that it could not easily correct."

---

StephenB wrote:

mke2fs creates a new file system, so I am puzzled why you'd want to do that.  If you are ok with the data loss, a factory reset would be the next thing to try.

 

I'd probably try booting w/o the volume check next myself.

---

Thanks for taking the time to respond and sorry my explanation was poor as I've been reading article after article to beef up my understanding without doing any harm.  Data loss is not okay in this case.  Over the years, my backup discipline atrophied and there is a lot of information I need to rescue.

Specifically, my focus is around mke2fs as my errors leads me to believe that I have a corrupt superblock on /dev/c/c.  My reasons for believing this are:

1. dmesg | grep EXT4

   EXT4-fs (dm-0): ext4_check_descriptors: Block bitmap for group 17216 not in group (block 623566614080)!
   EXT4-fs (dm-0): group descriptors corrupted!

2. mount /dev/c/c /c

   mount: wrong fs type, bad option, bad superblock on /dev/c/c,
          missing codepage or helper program, or other error
          In some cases useful info is found in syslog - try
          dmesg | tail  or so

3. from the fsck.log

   ***** File system check performed at Tue Feb  7 12:28:16 EST 2017 *****                                                 
   fsck 1.42.12 (29-Aug-2014)                                                                                              
   /dev/c/c: recovering journal                                                                                            
   /dev/c/c: Note: if several inode or block bitmap blocks or part                                                         
   of the inode table require relocation, you may wish to try                                                              
   running e2fsck with the '-b 32768' option first.  The problem                                                           
   may lie only with the primary block group descriptors, and                                                              
   the backup block group descriptors may be OK.                                                                           
                                                                                                                           
   /dev/c/c: Block bitmap for group 17216 is not in group.  (block 623566614080)                                           
                                                                                                                           
                                                                                                                           
   /dev/c/c: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.                                                                  
           (i.e., without -a or -p options)                                                                                
      

Running

fsck.ext4 -v -n /dev/c/c

spews out uncountable inode conflicts.

My understanding is that

mke2fs -n /dev/c/c -b 4096

would display any superblock backups and that I could then try something like

mount -t ext4 -o ro,noload,sb=BLOCK# /dev/c/c /c

and be able to squirrel away any data before a rebuild.

Right now I'm running

smartctl --test=long /dev/sd[abcd]

to get some sanity about the state of the drives.

Thanks for any insight or ideas!