December 27, 200718 yr Author ok, problem here since drive 2 still has legit data on it, apparently it is trying to do a pairity sync. this is taking FOREVER. is there anyway to format disk2 so that it just thinks its a new disk? possibly from the command line? because i am not seeing a button to do it thanks -derek
December 27, 200718 yr ok, problem here since drive 2 still has legit data on it, apparently it is trying to do a pairity sync. this is taking FOREVER. is there anyway to format disk2 so that it just thinks its a new disk? possibly from the command line? because i am not seeing a button to do it thanks -derek You must do a parity sync at this point, you have no choice if you want parity protection. It does not matter if you have data on the drives or not...as parity is calculated on the entire drive, not the files. If you want to use fdisk to delete the partition you can do so on the command line once you stop the array. Be certain you have the correct disk... a mistake here would delete data you did not intend to delete. What kind of parity speed is being reported? How many minutes are being predicted? On my 9 disk IDE based array with the same size parity drive as you it takes somewhere near 455 minutes at a speed of 17,800 KB/sec. (yes, over 7 hours) The speed is dependent on your slowest disk. If you are seeing speeds lots slower you probably have an issue with the cabling one your disks. (many round IDE cables are NOT good for high speed access) Using the wrong BIOS option on SATA disks will result in them being run in IDE emulation mode and very slow access... So... what speeds are being reported? The speed you are seeing might be very normal. Joe L.
December 27, 200718 yr Tom, This thread points out an oustanding issue with the unRaid ability to recover from a failed data disk if the potential replacement disk is bigger than the parity drive. He had a 300 gig parity drive and two 250 gig data drives. One of the data drives failed. He was running in a degraded state with a failed data drive and ordered two new 500 Gig drives. When he went to replace the failed disk, it complained it is bigger than the parity drive and will not start the array. This is where the user gets confused and attempts to swap the drives. This of course will not work as there are then multiple invalid drives. It appears as if we are forced to purchase a replacement data disk that is greater than or equal to the failed drive, but smaller or equal to the parity drive. How about an option to allow us to install the new 500 Gig drive, partition it with a partition sized as big as the PARITY drive (in this case partitioned as a 300 Gig drive) , and create a reiserfs on it and continue with the recovery. Then, when the parity drive is upgraded to a larger size at some future time, grow any data drives file systems to the new parity drive size. Thinking about it, it might be that a warning that the drive is bigger than parity and the excess will not be used might be enough. Recovery from parity/remaining data drives will re-write the partition table as well as the data... for all intents, it will be a 300 Gig drive at that point. Yes, the additional space on the replacement drive will be wasted until the parity drive can be upgraded, but it is better than running the array in a degraded state for an extended time period. Joe L. This exact case is handled by using the swap-disable feature. The correct procedure is: 1. Stop the array. 2. Power down the unit. 3. Replace the parity hard disk with a new bigger one. 4. Replace the failed hard disk with you old parity disk. 5. Power up the unit. 6. Start the array. When the system detects this config change, it will first copy the contents of the old parity disk (which is now in the disabled disk's slot) to the new parity disk, and then start a reconstruct of the disabled disk's data. There are a few ways we can improve this: - If system detects disabled disk got replaced with a new disk, but new disk is too big (ie, bigger than parity), system should generate documentation that suggests user should use swap-disable procedure (and instructions for doing so). Or, - Let parity disk slot 'float', that is, let system automatically assign parity disk upon creation of new array, and let parity disk slot change automatically as a result of replacing failed drives (as in this case). Reason we didn't do this is because hard drives and their controllers have different performance characteristics which might result in non-optimal choice for the parity disk. Might be time to rethink this though. Or, - Implement something like what you suggested: set the size of the new disk's partition equal to the old disk's. Then when a bigger parity disk is installed system could automatically extend any disk(s) file system.
December 27, 200718 yr Tom, This thread points out an oustanding issue with the unRaid ability to recover from a failed data disk if the potential replacement disk is bigger than the parity drive. He had a 300 gig parity drive and two 250 gig data drives. One of the data drives failed. He was running in a degraded state with a failed data drive and ordered two new 500 Gig drives. When he went to replace the failed disk, it complained it is bigger than the parity drive and will not start the array. This is where the user gets confused and attempts to swap the drives. This of course will not work as there are then multiple invalid drives. It appears as if we are forced to purchase a replacement data disk that is greater than or equal to the failed drive, but smaller or equal to the parity drive. How about an option to allow us to install the new 500 Gig drive, partition it with a partition sized as big as the PARITY drive (in this case partitioned as a 300 Gig drive) , and create a reiserfs on it and continue with the recovery. Then, when the parity drive is upgraded to a larger size at some future time, grow any data drives file systems to the new parity drive size. Thinking about it, it might be that a warning that the drive is bigger than parity and the excess will not be used might be enough. Recovery from parity/remaining data drives will re-write the partition table as well as the data... for all intents, it will be a 300 Gig drive at that point. Yes, the additional space on the replacement drive will be wasted until the parity drive can be upgraded, but it is better than running the array in a degraded state for an extended time period. Joe L. This exact case is handled by using the swap-disable feature. The correct procedure is: 1. Stop the array. 2. Power down the unit. 3. Replace the parity hard disk with a new bigger one. 4. Replace the failed hard disk with you old parity disk. 5. Power up the unit. 6. Start the array. When the system detects this config change, it will first copy the contents of the old parity disk (which is now in the disabled disk's slot) to the new parity disk, and then start a reconstruct of the disabled disk's data. Good to know it can deal with a failed disk and a replacement that is bigger than the parity drive. That was not immediately apparent to me. There are a few ways we can improve this: - If system detects disabled disk got replaced with a new disk, but new disk is too big (ie, bigger than parity), system should generate documentation that suggests user should use swap-disable procedure (and instructions for doing so). Better documentation is the key here. It is one thing to say use "swap-disable" but another to give detailed instructions that give comfort that data will not be lost in the swap of the drives. Or, - Let parity disk slot 'float', that is, let system automatically assign parity disk upon creation of new array, and let parity disk slot change automatically as a result of replacing failed drives (as in this case). Reason we didn't do this is because hard drives and their controllers have different performance characteristics which might result in non-optimal choice for the parity disk. Might be time to rethink this though. I don't like the automatic assignment...same reasons as you... even though larger disks often are faster, the controller might not be. Or, - Implement something like what you suggested: set the size of the new disk's partition equal to the old disk's. Then when a bigger parity disk is installed system could automatically extend any disk(s) file system. I kind of like the first and third options... perhaps as a choice in this situation. If they have a disk fail and the replacement disk is bigger than parity present the two choices with a pair of radio buttons to choose one or the other... 1. Power down and swap the two drives so parity is the bigger drive... be certain to do whatever you can to assist the person in identifying the correct two physical drives (give their slots/model/serial numbers in the detailed instructions) or 2. Leave the drives as they are and partition the replacement drive to be the same size as the drive that was originally there. The excess space will be unused until the parity drive is made bigger. This might allow the user to save a half hour or so needed to take the case apart to swap the drives. I would gladly use this option if the difference was only a few blocks of data, as with 500 Gig drives from different manufacturers. I personally would physically "swap-disable" the drives if it meant gaining 200 Gig (replaced 300Gig drive with 500Gig, as in this case) Now, if a third radio button choice was also there, to logically use the larger drive as the parity drive and have the system swap the roles of the slots (similar to your second option), that would be ok too. (parity drive assignment not automatically selected, but available as a choice) At least the user knows the new replacement drive is now parity and the old parity drive will now be used for data. More than anything else, better documentation is the key here. Biggest mis-understanding was that his disk1 that had the "red" indicator was OK since he could still read and write to it. Something big, bold, and RED needs to call attention to the fact that a drive needs to be replaced as soon as possible. It is clear the "red" indicator was not enough for this user. Joe L.
December 27, 200718 yr Author here is what i am seeing Total size: 488,386,552 KB Current position: 5,932,032 (1.2%) Estimated speed: 94 KB/sec Estimated finish: 83759.4 minutes
December 28, 200718 yr and I sent you an email yesterday too... I don't think I got anything from you - did you send from same email address that's registered on this forum?
Archived
This topic is now archived and is closed to further replies.