I've just replaced an Adaptec 1430A with an Supermicro AOC-SASLP-MV8. All the drives were recognized and I was able to assign them to their proper positions in the array. I also added a new drive - a recertified WD 1.5TB EARS (jumpered and precleared) - that was a replacement for a faulty drive. I ran a parity check last night and it found 3 errors. I looked through the syslog and discovered the following reference to a bad superblock on the recertified drive:

 

Nov 29 20:58:54 Media logger: mount: wrong fs type, bad option, bad superblock on /dev/md12,

Nov 29 20:58:54 Media logger:        missing codepage or helper program, or other error

Nov 29 20:58:54 Media logger:        In some cases useful info is found in syslog - try

Nov 29 20:58:54 Media logger:        dmesg | tail  or so

Nov 29 20:58:54 Media logger:

Nov 29 20:58:54 Media emhttp: _shcmd: shcmd (108): exit status: 32

Nov 29 20:58:54 Media emhttp: disk12 mount error: 32

Nov 29 20:58:54 Media emhttp: shcmd (109): rmdir /mnt/disk12

Nov 29 20:58:54 Media kernel: REISERFS warning (device md12): sh-2021 reiserfs_fill_super: can not find reiserfs on md12

 

and then further down it looks like the issue is addressed:

 

Nov 29 21:01:58 Media emhttp: shcmd (128): mkdir /mnt/disk12

Nov 29 21:01:58 Media emhttp: shcmd (129): set -o pipefail ; mount -t reiserfs -o noacl,nouser_xattr,noatime,nodiratime /dev/md12 /mnt/disk12 2>&1 | logger

Nov 29 21:01:58 Media kernel: REISERFS (device md12): found reiserfs format "3.6" with standard journal

Nov 29 21:01:58 Media kernel: REISERFS (device md12): using ordered data mode

Nov 29 21:01:58 Media kernel: REISERFS (device md12): journal params: device md12, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30

Nov 29 21:01:58 Media kernel: REISERFS (device md12): checking transaction log (md12)

Nov 29 21:02:00 Media kernel: REISERFS (device md12): Using r5 hash to sort names

Nov 29 21:02:00 Media kernel: REISERFS (device md12): Created .reiserfs_priv - reserved for xattr storage.

Nov 29 21:02:00 Media emhttp: resized: /mnt/disk12

Nov 29 21:02:00 Media emhttp: shcmd (130): chmod 700 '/mnt/disk12'

Nov 29 21:02:00 Media emhttp: shcmd (131): rm /etc/samba/smb-shares.conf >/dev/null 2>&1

Nov 29 21:02:00 Media emhttp: shcmd (132): cp /etc/exports- /etc/exports

Nov 29 21:02:00 Media emhttp: shcmd (133): killall -HUP smbd

Nov 29 21:02:00 Media emhttp: shcmd (134): /etc/rc.d/rc.nfsd restart | logger

 

There are also a whole lot of lines in the syslog referring to port 7 (the syslog which starts around 8pm last night was close to 300kb in size and too large to attach here):

 

Nov 29 20:48:48 Media kernel: /usr/src/sas/trunk/mvsas_tgt/mv_sas.c 20usr/src/sas/trunk/mvsas_tgt/mv_sas.c 2069:port 7 ctrl sts=0x199800.usr/src/sas/trunk/mvsas_tgt/mv_sas.c 2069:port 7 ctrl sts=0x199800.

Nov 29 20:48:48 Media kernel: /usr/src/sas/trunk/mvsas_tgt/mv_sas.c 20usr/src/sas/trunk/mvsas_tgt/mv_sas.c 2069:port 7 ctrl sts=0x19usr/src/sas/trunk/mvsas_tgt/mv_sas.c 2069:port 7 ctrl sts=0x199800.

Nov 29 20:48:48 Media kernel: /usr/src/sas/trunk/mvsas_tgt/mv_sas.c 207usr/src/sas/trunk/mvsas_tgt/mv_sas.c 2069:port 7 ctrl sts=0x199800.usr/src/sas/trunk/mvsas_tgt/mv_sas.c 2069:port 7 ctrl sts=0x199800.

 

I'm wondering now whether I should run another parity check now or check the filesystems of disk 12. Some wise counsel would be much appreciated. This is the first time since building the unRaid server 10 months ago that I've had parity errors. I have attached the bottom portion of the syslog, including the bad superblock.

 

Cheers, Ross

syslog.txt

What you left off was in between unRAID not finding a reiserfs superblock on the cleared disk, and the eventual mounting of the disk was this:

Nov 29 20:59:23 Media emhttp: shcmd (127): mkreiserfs -q /dev/md12 2>&1 | logger

Nov 29 20:59:23 Media logger: mkreiserfs 3.6.21 (2009 www.namesys.com)

Nov 29 20:59:23 Media logger:

Nov 29 21:01:58 Media emhttp: shcmd (128): mkdir /mnt/disk12

 

A cleared drive will not have a file system or a file system superblock.  The error you saw in the log was completely expected.

 

Once the file system was created, the superblock on the file-system was created, and the mount point created, and the disk mounted.

 

 

Thanks for the info - so I guess the parity errors are unlikely to be from the superblock issue? Should I just run another parity check?

Cheers

Yes, run another parity check.

OK, I'll run another parity check, Joe. Thanks again for your assistance with this - very much appreciated.

Thankfully, the parity check completed with no sync errors.