I found my disk7 showing DISK_DSBL in Red type.  I shutdown the array and checked all the cables then restarted with the same indication.

 

I keep 3 spare drives available so I replaced the drive with the same size drive but now I get a message that says "Replacement disk is too small"

I can refresh the array but it cannot be started

 

Old disk was

Disk 7 ST3750640NS_5qd22X2T (sdj)

 

New disk is

Disk 7 ST3750640NS_5qd22VVP (sdj)

 

Any thoughts on why it is not seen as a drive that is large enough to be a replacement?

Forgot to list that I am on unRAID Version: 5.0

System log is to large to upload.

My guess is that the drive you're trying to use has a gigabyte hpa, was the drive ever connected to a gigabyte motherboard?

 

Sent from a mobile device, sorry for any typos.

 

 

zip the syslog and attach.

I'd agree there's a good chance your replacement drive has an HPA.

 

Download the free HDAT2 utility -- get the ISO and make a bootable CD.  Boot to it, and use the SetMax function to be sure your drive is set to the maximum size (this will eliminate any HPA).

 

Then try it and all should be fine.

 

http://www.hdat2.com/

No HPA on the drive, thought about this as well but HDPARM -N shows no HPA.

 

I put the drive in my dev box last night and did a preclear there and put it back in my production box and this time it started to rebuild the disk.

 

However now that the rebuild is done, there are no files on the drive   The system does show 1,520,286 writes to the disk, just no files.

 

Anyway to force a restore at this point?

 

Current syslog attached

syslog-2013-10-11.zip

Anyway to force a restore at this point?

 

No.  If the rebuild produced an empty disk, then somehow all of the files had been deleted off the disk; and so the rebuild just mirrored an empty disk.

 

Are you sure the disk in fact had files on it?   

 

The number of writes is fine -- when UnRAID rebuilds a disk, every sector is written ... it makes no difference if there was actual data on the disk.

 

You may be able to restore missing files with reiserfsck.

dgaschk way to go, thanks for your comment.

 

With the rebuild not doing what I was hoping it would I tried reiserfsck from my dev box on the failed drive.

 

Was able to get back 376 GB of blu-rays and all of my West Wing series.  I lost two blu-rays from the original disk but this is much better than having to do a re-rip of all of those movies.

 

Once all the movies were back on the current disk I did a Parity-Check and then to see what would happen I pulled the drive and replaced it with another spare.  After the rebuild of the new disk I am surprised or maybe not that once again that the entire disk is again EMPTY.  Once again, 430 GB of blu-rays and 140 GB of West Wing simply gone from the array and the rebuild process not bringing them back.

 

Is there a way to query the parity disk to see exactly what is and is not on it?  Or is there a method of checking that the parity drive has any data on it to do a rebuild?

 

 

The disk was (unintentionally) formatted. You can run reiserfsck on the /dev/md7 device in the server to recover the files again while keeping parity in sync. See check disk filesystems in my sig.

Is there a way to query the parity disk to see exactly what is and is not on it?  Or is there a method of checking that the parity drive has any data on it to do a rebuild?

See here.

jonathanm thanks for the hit,

 

The current problem is that the rebuild is not working so either there is no parity being saved or the rebuild process is simply broke for some reason.  There is no misunderstanding of how parity works, but whether there really is any parity at all being created or if there is a problem with the parity drive or the rebuild process.  You can usually use an XOR check of a physical raid array to see if the parity really is being created and what can and cannot be recovered.  Since this is a separate parity drive that function would not work, but the hope would be that there would be a process.

 

So with the parity valid in the array, I removed a drive and replace it with a new drive.  Once the system restarts the system fires off a rebuild.  After the rebuild the new drive is suppose to have all the files restored to it from the original drive. After the rebuild is listed as complete there are no files rebuilt onto the new drive.

 

I also put the replaced drive in my dev box and all of the files are on the drive, this would indicate that there is a problem somewhere in my production box with either the parity process the parity drive or the rebuild process.  To figure out where the problem is and why the system is simply not doing what it is suppose to do I needed to pick one side of the problem and I really cannot look at the rebuild process if I am unsure if the system is even providing a means for it to work.

 

I am currently replacing the parity drive and rebuilding the parity to see if this solves the problem.  Once the parity is valid I will copy the files back onto the current empty drive in the array and then go through the removal, replacement and rebuild process again to see what happens.

 

 

 

Is there a way to query the parity disk to see exactly what is and is not on it?  Or is there a method of checking that the parity drive has any data on it to do a rebuild?

There is no data on a parity disk in the sense you are asking.  All there is is enough information that if a single drive fails then the combination of the parity disk and all the others allows the failed one to be recovered.

itimpi, this is still the original question...

 

Lets first settle on the fact that no one should ever state or agree there is nothing stored on the parity drive, this is simply not correct.  If there really is nothing there than the system should not need it and the array should work without it even for a rebuild.  The issue with my current system is if it is valid or even there at all.  I assure you there should be something there if the system is running as it is suppose to.

 

So my question is if the "enough information" is really there and able to be used by the rebuild process.  One of these two areas of the system, either the parity or the rebuild are not working as they are suppose to.

 

No one should say I have not done everything I should to check the rebuild process from reading my post.  I have added files to a drive, performed a parity check, replaced the drive, system performs a rebuild, new drive is empty.  The original drive when placed into another system contains all the files that should have been rebuilt onto the new drive.

 

There is a way to check parity, the array does it all the time.  But is there a way to see if the array is correct when it shows Parity is valid.

 

 

By no data I mean there is no file system that can be examined.  Parity works at the disk physical block level and is independent of the file systems on the disks.  What there is is data at the block level that can be combined with equivalent blocks from good drives to reconstruct blocks on a failed drive.

There is a way to check parity, the array does it all the time.  But is there a way to see if the array is correct when it shows Parity is valid.

Sure.

1. Run a correcting check, confirm zero errors.

2. Pull ONE data drive out, start array in degraded mode.

3. Compare the parity emulated data drive with the data on the removed drive.

 

When a drive is disabled in the array, starting the array will allow full access to the files on the disabled drive, by accessing all the remaining drives and the parity drive to calculate what should be on the disabled drive. Whatever is showing on the disabled drive will be rebuilt on its replacement. If you format or do any data operation on the emulated drive, that change will be rebuilt on the new drive. It's risky, but you can continue to use the array with one drive removed, and that drives contents are fully available for any operation, including adding new files to that drive. All operations to the missing drive are done on the parity drive, and when you replace the missing drive, it's rebuilt with all the changes that have been applied to the emulated drive, it's not identical to the failed drive, unless nothing was changed on the emulated drive.

 

The parity drive does have a valid partition, but there is no valid file system, so stating there is nothing of value only on the parity drive is perfectly valid. The data on the parity drive is only usable as the final factor in an equation that uses all the other data drives. If you pull the parity drive out of the system, it's totally unreadable as far as any complete files. There is no point in trying to read the parity drive directly.

The concept of what you said is accurate, but just to be nit-picky, a couple of comments aren't entirely correct ...

 

All operations to the missing drive are done on the parity drive ...

 

Any operations on the "missing drive" do indeed result in the parity drive being updated, so the total set of all other data drives plus parity can reconstruct the correct data.  But it's more accurate to say that operations to the missing drive result in updates to parity so the emulated drive has the correct content than to say the operations are actually done on the parity drive.  Only those bits that result in changed parity are modified on the parity drive.

 

 

If you pull the parity drive out of the system, it's totally unreadable as far as any complete files. There is no point in trying to read the parity drive directly.

 

Actually, in some situations, the parity drive is completely readable.  e.g. if you have a 2-drive system, the data and parity drives will be identical.    That will also be true for a 3-drive UnRAID system (of which there are many, since this is the limit for Basic) until the 2nd data drive is actually written to (which may be a good while with high-capacity drives and high-water allocation).

 

But I agree that you should NOT plan on reading the parity drive directly -- except for those special cases, it will not have any useful info.

 

 

jonathanm thanks for the feedback...

 

As you can tell from my previous posts this is what I have already done.  I am not really looking for any explanation as to how this works, I had that before I posted, this issue is the system is not working the way it should and I need to figure out why.  A secondary tool to check the parity like I would in a RAID 5 system would be the fastest way to determine where to start tracking down the problem but without one available I moved on.

 

I have an array in which I added files to a drive, performed a parity check with no errors reported, replaced the drive with a new drive, system performs a rebuild no errors reported, new drive is empty, no files or folders, simply nothing to see here.

 

If I put the original drive into my dev box all the files that should have been rebuilt onto the new drive are there showing that the files were on the drive when in the array, the parity-check was ran with no errors and should have been recovered to the new drive.

 

There is something not working the way it should, the question is what is broke the rebuild or the parity.  I replaced the parity drive and it is building now.  Once the parity is valid I will copy files back onto the array and then go through the removal, replacement and rebuild process again to see what happens.

 

There is no cache drive in the system, I do use Split level and have it set to "(".  For my test I am copying The West Wing (NBC_DRAMA) to the array.  All seven seasons would normally be placed on a single drive, but for the test I am only coping season one to speed things up.

 

There is one hour left on the parity build, I will post back when I run the next test.

 

 

Once all the movies were back on the current disk I did a Parity-Check and then to see what would happen I pulled the drive and replaced it with another spare.  After the rebuild of the new disk I am surprised or maybe not that once again that the entire disk is again EMPTY.

This statement is what causes me to think that you are not understanding the process. At no time during this process should you lose access to the files on the disk. The rebuild shouldn't show any change to the content, only the status indicator of the disk. Are you saying that you checked the array and had access to the emulated disk after you pulled it and started the array, and during the rebuild process the files were there, but after the rebuild completed the files were gone? The /dev/md? device or the disk or user share should have exactly the same content during the entire process, no matter whether there was the disabled disk, the fresh disk waiting to rebuild, or the rebuilt disk. Since you are planning more testing, this time start the array after you pull the disk and before you replace it, and check to see if the files are still there. If they are, the rebuild should succeed. If they are gone, report back with a syslog.

 

You asked for a method to check whether parity was working as it should, and this is it. Remove the drive, start the array with one disk missing and see if that disks' content is still available.

As Jonathanm noted, you're doing something wrong here if the disk is not being rebuilt correctly.

 

First, you said you did a parity check => were the results zero sync errors?  ... and if not, was it a correcting check (so any errors were fixed) ??

 

Assuming you in fact had a good correcting check with no errors; then describe EXACTLY what the process was that you followed -- in fact, post shots of the Web GUI's main page after each step.

 

If you Stop the array;  unassign a disk; then Start the array, you should -- as Jonathan noted -- see a "Missing" disk ... but you should still be able to read the content of that disk.  i.e. if Disk3 is "missing", you should still be able to access \\Tower\Disk3  with no problem.

 

Then if you Stop the array; reassign the disk; and Start it up again, the array should rebuild the disk with the SAME content it originally had.

 

Is that what you're doing?    If not, what's different?

 

Rebuilding a drive restores the drive partition. The unRAID driver is not aware of files or file systems. The restored disk will be identical to the original (or rather the currently emulated version), including any files system errors. File system errors can only be fixed with reiserfsck. The disk appears to have been formatted. When an array disk is formatted this updates parity. Running reiserfsck on the array disk as instructed in my sig will recover the same files that you've previously recovered.

dgaschk,

 

As I stated before I did that with the original drive and was able to recover most of the files using reiserfsck that were still on the drive that unRAID failed to recover during it's rebuild.

 

I am not trying to recover files right now, simply trying to find out why my current unRAID array cannot recovery from a replaced drive as it is suppose to do.

 

Back to it..sad to say.

 

New parity drive, array shows Parity is valid.

 

Using FreeFileSync update array with The West Wing (NBC_Drama) folder.  Folder and all files placed on disk (sda) and can be played via XBMC.  Performed another Parity-Check with Write corrections to parity disk, array shows Parity is valid.

 

As per the steps from the unRAID Wiki at (http://lime-technology.com/wiki/index.php/Replacing_a_Data_Drive) Stopped the array, powered down, remove drive from array, replaced with new drive, restart the array select "I'm sure" and away we go with the rebuild.  After rebuild is complete there are no files or folders on drive.

 

This time I mounted the original drive in array via SNAP as drive/sadday, all files and folders are present on the drive and can be played via XBMC.

 

Something is broke here either in the parity or the rebuild.  If there is no way to get to the parity to see if it really is valid is there a way to verbose the rebuild to see what it is doing?

 

Stopped the array, powered down, remove drive from array, replaced with new drive, restart the array select "I'm sure" and away we go with the rebuild.  After rebuild is complete there are no files or folders on drive.

So you just chose to ignore the diagnostic steps I outlined earlier? Did you start the array with the drive missing and check the contents of the missing drive as it was being emulated by parity? It's hard to help someone who won't follow directions.

 

Also, using the /dev/sd* designations isn't correct when dealing with the parity protected array. If you copied files to the /dev/sda1 device instead of the array device, that would explain everything. If you want to test this, do a correcting parity sync after copying data to /dev/sda1, it should show errors for every write you made, and after the parity is updated to reflect the current contents of the disk, the rebuild will work as you expect. To copy to the protected array, you must use either /mnt/disk*, or if you want to copy to a user share, /mnt/user/sharename.

jonathanm,

 

Did not skip anything, there are no problems with the emulated drive nor have I indicated there were.

 

The file copy is done through a user share called Movies i.e. "\\tower\Movies\TV Shows\The West Wing (NBC_Drama)".  The designation of sda is the physical drive location as in "/dev/md1 /mnt/disk1 /dev/sda" the array placed the file on which can be seen by browsing to the drive share "\\tower\disk1" and seeing the files there.

 

I stay away from logical designations from the end user world when troubleshooting hardware as those change often...its a habit from to many years ago and is hard to break.  I track all the drives by serial number first than location and then logical designation as ST2000DM001-1CH164_W3403063 (sdd) /mnt/disk1.  I keep this in a spreadsheet for both my arrays and my three sans so if there is a problem with a drive there is no doubt where it is and what replacement to use.

 

Also I did do a Parity-Check with Write corrections which shows no Sync Errors and is suppose to update the Parity to basically say that I know the parity is wrong and the drive is correct.  If the system shows Sync Errors as 0 everything should be good in the array and I should be able to replace any drive in the array and have the system perform a rebuild.  This is the only thing that is not working correctly.

 

The steps for this are clearly outlined on the official Wiki and state "Hefty disk activity and main page will show lots of reading on "the other" disks and writing on new disk as data is being rebuilt."  After the rebuild I am expecting based on this for the data to return to the new drive but it never does.

 

Based on what you have said so far are you stating here that the Wiki is wrong and the data should not come back after the rebuild, or are you stating that after you perform a "Parity-Check with Write corrections" that the parity is not actually correct and therefore you cannot get the data back?  Or is there a missing step after the rebuild is complete?

 

If you could tell me which one is wrong I could work from that point.

 

My last test was as follows...try not to leave any step out for you this time

Stop array and select New Config from Utilities

Add all drives except test drive to array and restart

Run "Parity-Check with Write corrections" and make sure there were no Sync Errors

Shutdown array and shutdown unRAID

Remove test drive and clear it

Put test drive back in system and start unRAID

Stop the array and add drive

Start array and copy files to array then check if files are written to new drive and test files

Run "Parity-Check with Write corrections" and make sure there were no Sync Errors

Remove drive and see if files are still available

Shut down array and replace drive

Restart unRaid

Tick the "I'm sure" checkbox and start the array

Wait for rebuild to complete which it does without errors and the files are suppose to be on the new drive

However there are no files on the new drive