Parity does not have a file system type.

 

I figured that, but to get that error on disk3 aka sdg aka md3?

and the md3 vs. sdg thing.  the Linux kernel controls the sdX assignment and those can change from boot to boot, it all depends on the order in which pieces and parts are discovered.

 

unRAID has to then find the drives it needs and mount/assign them correctly.  The mdX devices are just that.

 

Understand all that.  But unRAID does not display the md# associated with disk# and sdX.  If unRAID cannot control certain assignments, then at least provide the equivalents that are used by unRAID and the kernel so that when there is an OS output of "error involving md#" I can read the syslog, or the web server or unMENU to determine what unRAID has assigned as disk#/sdX for md#.

 

I am assuming that md3 is disk3 is sdg as I have found no such explicit definition anywhere...

and the md3 vs. sdg thing.  the Linux kernel controls the sdX assignment and those can change from boot to boot, it all depends on the order in which pieces and parts are discovered.

 

unRAID has to then find the drives it needs and mount/assign them correctly.  The mdX devices are just that.

 

Understand all that.  But unRAID does not display the md# associated with disk# and sdX.  If unRAID cannot control certain assignments, then at least provide the equivalents that are used by unRAID and the kernel so that when there is an OS output of "error involving md#" I can read the syslog, or the web server or unMENU to determine what unRAID has assigned as disk#/sdX for md#.

 

I am assuming that md3 is disk3 is sdg as I have found no such explicit definition anywhere...

md3 is disk3... md2 is disk2, md10 is disk10, etc.

 

The linux device is shown on the "devices" page and is the three letter name in parens. (sda, sdb, hda, hdb, etc)  It can change from one boot to the next as it is assigned as each disk initially spins up and is discovered by the linux kernel.

 

The "device inventory" is also available in your system log  (disk0 is your parity disk).

Sep 10 21:36:14 Tower kernel: md: import disk0: [8,48] (sdd) ST31000340AS    9QJ0JPJS size: 976762552

Sep 10 21:36:14 Tower kernel: md: import disk1: [3,64] (hdb) HDS725050KLAT80 KRVA03ZAG3V5LD size: 488386552

Sep 10 21:36:14 Tower kernel: md: import disk2: [22,0] (hdc) ST3400620A 5QH00QPN size: 390711352

Sep 10 21:36:14 Tower kernel: md: import disk3: [22,64] (hdd) HDS725050KLAT80 KRVA03ZAG4V99D size: 488386552

Sep 10 21:36:14 Tower kernel: md: import disk4: [33,0] (hde) ST3400620A 5QH00PF4 size: 390711352

Sep 10 21:36:14 Tower kernel: md: import disk5: [33,64] (hdf) WDC WD5000AAKB-00YSA0 WD-WCAS88067391 size: 488386552

Sep 10 21:36:14 Tower kernel: md: import disk6: [34,0] (hdg) ST3400633A 3PM0BE0T size: 390711352

Sep 10 21:36:14 Tower kernel: md: import disk7: [57,64] (hdl) MAXTOR STM3500630A 5QG00FTK size: 488386552

Sep 10 21:36:14 Tower kernel: md: import disk8: [57,0] (hdk) ST3750640A 5QD29FXK size: 732574552

Sep 10 21:36:14 Tower kernel: md: import disk9: [56,0] (hdi) ST3400633A 3PM0LZ3D size: 390711352

Sep 10 21:36:14 Tower kernel: md: import disk10: [3,0] (hda) ST3750640A 5QD2AX3G size: 732574552

Sep 10 21:36:14 Tower kernel: md: import disk11: [8,32] (sdc) WDC WD10EACS-00D WD-WCAU44206983 size: 976762552

 

Joe L.

md3 is disk3... md2 is disk2, md10 is disk10, etc.

 

So for the sake of clarification, if I reassign disks in unRAID, say change disk1 to disk8 and disk8 to disk1, restart, then Linux will also change the md# assignments to reflect the new unRAID change, even if I do not physically change the hard drives to others' SATA ports?

 

The linux device is shown on the "devices" page and is the three letter name in parens. (sda, sdb, hda, hdb, etc)  It can change from one boot to the next as it is assigned as each disk initially spins up and is discovered by the linux kernel.

 

The "device inventory" is also available in your system log  (disk0 is your parity disk).

 

At the time, I could not access unRAID's web server, unMENU nor telnet.  And the OS was coughing up the REISERFS error non-stop so I couldn't "break in" at the keyboard to enter commands directly at the console.

 

---

 

NOW, on to the results of my parity check (without error correction), it finished with 1,530 errors but no REISERFS errors at all, like before.  And it still shows "PARITY VALID" under Array Status after the parity check (no corrections allowed) was completed.  So now I'm stumped.  Since I never got the chance to determine if the data rebuild on the newly installed 3TB drive was completed with no errors as I encountered the issue I mentioned several posts ago, what should I actually trust?

 

Should I assume the parity is incorrect and simply redo the parity check with error correction enabled?

 

Should I rebuild the data on the newly installed 3TB drive?

 

Should I reinstall the old 2TB drive and build new parity, then put the new 3TB and build data onto it?

 

The jist of the parity error entries is thusly:

 

Oct  3 23:04:36 UnRAID kernel: md: parity incorrect: 4025044512 (Errors)

 

As a reminder, I did a SMART test on the parity and md3 drive (the source of the non-stop REISERFS errors initially) with zero errors, and attempted a file system check via unMENU but it came back with "no file system" detected message.

syslog-2011-10-04.txt.zip

Wow.  This is turning into a C-F.

 

It appears the Web GUI froze, stopped or is somehow no longer responding right in the middle of a parity check with error correction.

 

I decided that any step I take from the SNAFU I experienced during my last 3TB data disk upgrade would involve updating the parity data itself, so I simply re-ran the Parity Check with Error Correction enabled.

 

There was no restart since I performed the first Parity Check.

 

So after roughly 8 hours, the web server is unresponsive, but at least unMENU, telnet and network file sharing still are functional, so I performed a reboot via the telnet and am starting as if I am replacing the last hard drive again.

 

I captured the syslog via unMENU, but I couldn't determine anything within it to determine a catastrophic issue occurred that may have led to an unresponsive web GUI.

 

b12 is definitely NOT ready for prime time as too many issues have arisen that has now potentially left me with corrupted data due to b12 unable to cope with an issue(s) resulting in significant disruption in its functioning, so much so that could lead to syslog not being captured (as occurred when I first encountered issues).

syslog-2011-10-04.txt.zip