So, I just finished reconstructing all that I could of three disks that I had issues with after replacing a port multiplier and have found that one of the three has some bad blocks.  I was going to attempt a simple copy in MC to a spare disk that I already have in my enclosure, but when it reaches a bad block area, it just sort of freezes and never does anything.  Is there a way to kill that process instead of just doing a hard reset on the unRAID box?  I end up unable to stop the array or anything when it gets to a bad block.

 

Anyway, I now figure I need to just do a block-by-block copy of that drive to the spare.  Will a simple dd going drive to drive do the job or should I use dd_rescue or a dd with noerror?  Or, should I reconstruct parity without the blank spare, remove the bad drive after it's finish and then rebuild parity to the spare?  The only reason I don't want to do that is because the server will be offline for at least 10 hours, but bigger sacrifices can be made

 

I'm a novice at best and my searches are only getting me more confused, so any help will be appreciated.

Is there a way to kill that process instead of just doing a hard reset on the unRAID box?

 

You could try opening another session, then doing a ps -ef | less look for the mc process id

then do a

kil (pid)

if that does not work try

kill -9 (pid)

 

Will a simple dd going drive to drive do the job or should I use dd_rescue or a dd with noerror? 

I would try dd with noerror first.

If that does not work try

dd_rescue.

 

have you done a smartctl -t long /dev/sd? on the drive in question while the array was stopped?

 

 

Or, should I reconstruct parity without the blank spare, remove the bad drive after it's finish and then rebuild parity to the spare?

 

You can do it either way. You just have to remember to use the /dev/md? device if the drive is part of the array.

If you are doing this outside of the array, then use the /dev/sd? devices.

 

If you write to a /dev/sd? device that is actually managed by a /dev/md? device, the results could be unpredictable.

 

Thanks for all the suggestions!

 

I haven't tried the smartctl long test yet, but this drive has been showing errors for a while and the bad block was quite long. The smartctl test I did run a while back did show some issues, but I don't remember what they were...I just remember it wasn't a pass with flying colors like the others I ran it on.

 

There is one other option I'd like to try, but not sure if it would work.  Say I have /dev/sdb that is managed by /dev/md5 and /dev/sdd that is currently unassigned.  Can I do a dd conv=noerror if=/dev/sdb of=/dev/sdb (or would it be dd conv=noerror if=/dev/md5 of=/dev/sdb?) while the array is started, or do I have to stop it?  I'd say it would be wise to have it stopped regardless, but I'm just curious.

 

 

 

I'd say it would be wise to have it stopped regardless, but I'm just curious.

 

I would stop the array, then work on the /dev/sd? devices.

I still suggest the -t long test (takes about 2 hours).

Then dump the smartlog with

 

smartctl -d ata -a /dev/sd? > smartctl.log.sd?

 

See what it says. with

less smartctl.log.sd?

 

Thanks for all the suggestions!

 

I haven't tried the smartctl long test yet, but this drive has been showing errors for a while and the bad block was quite long. The smartctl test I did run a while back did show some issues, but I don't remember what they were...I just remember it wasn't a pass with flying colors like the others I ran it on.

 

There is one other option I'd like to try, but not sure if it would work.  Say I have /dev/sdb that is managed by /dev/md5 and /dev/sdd that is currently unassigned.   Can I do a dd conv=noerror if=/dev/sdb of=/dev/sdb (or would it be dd conv=noerror if=/dev/md5 of=/dev/sdb?) while the array is started, or do I have to stop it?  I'd say it would be wise to have it stopped regardless, but I'm just curious.

I'm not sure if you can write to /dev/sdb while the /dev/md5 object is controlling it. It might have an exclusive lock on it.

 

If you do stop the array, and then write to /dev/sdd and make any changes you must then re-compute parity by requesting a full parity check once you re-start the array.  Changes made behind the "md" driver's back are guaranteed to cause parity errors.

 

As far as reading and writing the exact same file (/dev/sdd)... never tried it.  Don't know how it will work.

If you had space, you could dd to another disk, and then back, even if you dd | compress - >file and then uncompress < file | dd ...

The empty space on the drive would compress VERY well.

 

Joe L.

As far as reading and writing the exact same file (/dev/sdd).

 

I don't think this is what he meant, but if it is, then it's a sure way to mess it up.

It will succeed to read and write, but there is no guarantee with what you come out with.

 

As far as md5 having and exclusive lock. I do not think this is the case.

You can write to the underlying device while and md device is active. However, you will damage the data.

 

I would stop the array, salvage what you can.

Then restart the array, or RE-STORE the array and recreate parity..

 

Or you can add the new drive, recalculate parity, then remove the old drive, and recalculate parity. (lengthy).

 

As far as reading and writing the exact same file (/dev/sdd).

 

I don't think this is what he meant, but if it is, then it's a sure way to mess it up.

It will succeed to read and write, but there is no guarantee with what you come out with.

 

As far as md5 having and exclusive lock. I do not think this is the case.

You can write to the underlying device while and md device is active. However, you will damage the data.

 

I would stop the array, salvage what you can.

Then restart the array, or RE-STORE the array and recreate parity..

 

Or you can add the new drive, recalculate parity, then remove the old drive, and recalculate parity. (lengthy).

 

I re-read his question.

To copy from the one disk's partition in the array, to the other's that is currently un-assigned you need to remember that the /dev/md5 is actually /dev/sdb1    <-- the first partition on /dev/sdb

 

So, if the two disks are the same exact size, you can do

dd conv=noerror if=/dev/sdb of=/dev/sdd

or

dd conv=noerror if=/dev/md5 of=/dev/sdd1    <--- assuming the disk is partitioned the same as /dev/sdb with a single partition of the same type.

 

Joe L.

As far as reading and writing the exact same file (/dev/sdd).

 

I don't think this is what he meant, but if it is, then it's a sure way to mess it up.

It will succeed to read and write, but there is no guarantee with what you come out with.

 

As far as md5 having and exclusive lock. I do not think this is the case.

You can write to the underlying device while and md device is active. However, you will damage the data.

 

I would stop the array, salvage what you can.

Then restart the array, or RE-STORE the array and recreate parity..

 

Or you can add the new drive, recalculate parity, then remove the old drive, and recalculate parity. (lengthy).

 

I re-read his question.

To copy from the one disk's partition in the array, to the other's that is currently un-assigned you need to remember that the /dev/md5 is actually /dev/sdb1     <-- the first partition on /dev/sdb

 

So, if the two disks are the same exact size, you can do

dd conv=noerror if=/dev/sdb of=/dev/sdd

or

dd conv=noerror if=/dev/md5 of=/dev/sdd1     <--- assuming the disk is partitioned the same as /dev/sdb with a single partition of the same type.

 

Joe L.

 

Thanks, this makes sense to me then.  I think it's probably safest for me to just stop the array and do the first example overnight when no one needs any access to the array.  This way I'll have at least two copies of the same data and when i swap disks, I'll have the old drive available if anything goes wrong.

 

After what happened earlier in the week, I'm not too comfortable with taking any chances anymore, so I want to cover as many bases as possible.

 

One more question regarding smartctl - if I end up successfully completing the dd to the new drive, get it reassigned to the current drive's position and recalculate parity, can I do the smartctl on the old drive if I have it unassigned with the array started?  I'm assuming smartctl can be run on any drive that is unassigned and not part of a running array.

  I'm assuming smartctl can be run on any drive that is unassigned and not part of a running array.

As far as I know, you can run it on any drive at any time. in the array or unassigned. 

  I'm assuming smartctl can be run on any drive that is unassigned and not part of a running array.

As far as I know, you can run it on any drive at any time. in the array or unassigned. 

 

True, but any drive activity holds the smartctl test while the activity is taken care of.

This will lengthen the smartctl process and/or the read/write operation.

 

Just choose a time when the system is quiet. It doesn't have to be unassigned, just a bit quiet.

Well, I let a parity sync complete and then swapped out drives last night and let it rebuild.  I thought it was going to take a lot longer than it did (>4hrs for a 500GB drive that was full and I have 2.7TB of total data on 4.5TB of disk).

 

Everything went perfectly fine though.  Thanks for the help!