Firstly nothing was being written to the disk

problem i had added a new harddrive to my array the other day and not sure if the parity was valid for new hardrive.

 

disk 1 went faulty. checked smart reports etc the disk is fine. i ran resesfs check came back clean.

 

would you

A. do the new config and hope its all good

B. do the re enable procedure knowing that your parity might not have been valid since you added that new hardrive to array?

What command, exactly, did you type to check the file system? How you answer that question determines the course of action IMHO.

 

As always, please post diagnostics as requested in the sticky at the top of this forum.

i used the one built in to unraid 6.1

syslog.txt

reiserfsck 3.6.24

 

Will read-only check consistency of the filesystem on /dev/md1

Will put log info to 'stdout'

###########

reiserfsck --check started at Sat Dec  3 11:10:01 2016

###########

Replaying journal:

Replaying journal: Done.

Reiserfs journal '/dev/md1' in blocks [18..8211]: 0 transactions replayed

Checking internal tree..  finished

Comparing bitmaps..finished

Checking Semantic tree:

finished

No corruptions found

There are on the filesystem:

Leaves 476077

Internal nodes 2945

Directories 10572

Other files 36621

Data block pointers 476448905 (0 of them are zero)

Safe links 0

###########

reiserfsck finished at Sat Dec  3 13:53:44 2016

###########

How exactly did you add a disk in such a way that you are not sure your parity is valid?

i stopped array added new disk

and it never completed the new parity. i vaguely remember it saying error code -5

i was doing a parity check on the system with the new drive when the drive 1 came up red

Doesn't sound like you have any choice except new config. Did you preclear the new drive? Have you checked SMART for all drives? Instead of syslog for V6 you should always go to Tools - Diagnostics and post the complete diagnostics zip which contains syslog, SMART for all drives, and many other useful things.

see attached

zip.zip

If you precleared the new drive, then parity would remain valid when you added it and unRAID would only need to format it.

 

If you didn't preclear the new drive, then when you added it to the parity array unRAID would clear it so parity would remain valid, then format it.

 

In neither of these cases would unRAID rebuild parity, so parity should be valid if you did either of these. Either of these would be considered a "standard" way to add a new drive to the parity array.

 

So I'm still unclear why you think parity wasn't valid. How exactly did you add the new drive?

 

Also, unRAID only disables a drive when a write to it fails. So either something was written to the drive and that failed, or unRAID tried to read the drive and when that failed, it calculated the data it was trying to read and tried to write that data back to the drive and that write failed.

 

SMART for all disks looks OK, and I can see disk 1 is disabled, but I don't actually see the error that disabled it. Did you reboot after that happened?

so i did a few reboots in the hope that the drive would magically be undisabled. nope

so i currently did a new config, your right in your description and my parity must have been valid and i might have confused it with a parity sync check or something.

either way i'm way too far in the deep in now, i'm doing a new config and 5 hours left to completion. i just hope i didn't lose any old data

 

another question how do i know if my power supply is adequeate for the number of drives i have. does unraid have a built in thing that says low power supply

A little late now, but what I was looking for was the device that gave you a clean file system check. It was /dev/md1, which means the file system you were looking at was the emulated one calculated by parity, NOT the physical disk. Rebuilding was the proper course of action given this piece of info. I'd recommend running the file system check again after the new config parity is built and checked. The red ball means a write failed to the physical disk, likely causing a small amount of corruption. You stated that nothing was being written, but unraid only red balls a disk when a write fails, so most likely either some file system housekeeping write failed, or some other background process tried to write to the disk. The write was not committed to the physical disk in any case, only parity was updated.

so i did a few reboots in the hope that the drive would magically be undisabled. nope

This would never happen. The only way rebooting could affect your disk configuration is if somehow your super.dat got corrupted, in which case rebooting would mean it would completely forget your disk configuration.