September 6, 200916 yr Hi All,  I'm running Unraid 4.4.2 on a full slackware install (maybe relevant, maybe not). Anyway, I noticed my HDD light on constantly today and when I went to use the unraid server it seemed a little "off color".  Long story short, there were 1000+ errors on 'drive 3' (500gig IDE drive).  After a reboot, unraid is still working, I can still get to the disk share via \\server\disk3 and I can also see it mounted via 'df -h'. I am concerned that I will lose data on this drive and I want to replace it with a SATA 1TB drive.  Would I need to follow this process:  1) 'Stop' the array 2) 'Unassign' disk 3 3) Shutdown the server 4) Replace IDE disk with SATA disk (bigger capacity) 5) Startup server 6) Assign new SATA disk to disk 3 7) Do a parity check / rebuild (??)  Also, is it possible to assign my current parity drive as disk 3 and not lose any data?  Syslog snippit is below: Sep 6 22:30:28 TOWER kernel: md: disk3 removed    Â
September 6, 200916 yr Author disk3 device: pci-0000:06:00.1-ide-0:1 (no device) Â Going from "http://lime-technology.com/forum/index.php?topic=2601.msg21033#msg21033" Â "Unraid will simulate a failed disk" Â Would that be the reason I can still access all of my shares? Â Â
September 6, 200916 yr Your array is definitely running in simulated disk mode. This means that although you are able to see disk3 contents, they are actually being simulated by using the contents of the other data disks + parity. Accesses to disk3 contents will be degraded, but perhaps not by as much as you might think. Many times users are able to use a degraded disk and not even know! The scary thing is that if the disk has really failed, the entire contents of disk3 could disappear in the event of another failure in the array. Fixing this type of thing quickly is a priority!  There are two possible root causes to the failure - and determining which is important. The disk may have actually failed, meaning that it needs to be replaced. Or the disk may have just lost contact with the computer and APPEAR to have failed from the unRAID perspective. In this case, usually a tweaking or replacing of the data and/or power cables can bring the disk back to life. But it is also important to know that regardless of the cause, the array will not be corrected without your intervention, and that following the right steps at this point is quite important.  It is unfortunate if you rebooted the server without taking a screenshot and capturing a full syslog. Every time you reboot the syslog is completely refreshed and hints of what caused events like this are lost. All we know at this point is that unRAID removed the disk from the array. The best way to know if the disk is good or bad is to look at its smart report. (For more info. go to the troubleshooting link in my sig and read about smartctl).  But before you can take a smart report, you need to find out whether the drive is even being recognized at the moment.  Run the command ...  ls -l /dev/disk/by-id  from a telnet session with the server. It should help you find the disk and learn what its id is (e.g., sda, sdb, ...).  Once you know, you need to run the command ...  smartctl -a -d ata /dev/sd?  where sd? is the id you learned above.  Post the contents of the smartctl report here and I can help advise you as to whether the disk is actually bad. (Again, refer to the troubleshooting link for more detail and help in how to capture and post this report).
September 6, 200916 yr Whatever you do ... DO NOT press the "restore" button. If you do replace the disk, use the "Start" button...  Pressing "restore" will throw away the parity data and start a new calculation with the currently assigned and working drives. If you really have had a failed drive, all data on it will be lost.  There is an exception to this rule, but for now, pretend the "restore" button does not exist.  If your replacement SATA drive is larger than your existing parity drive, then there is a procedure to handle that. It is a "parity-swap" process You assign your current parity drive as the failed drive, and assign a new parity drive to the parity slot. It is described here: http://lime-technology.com/wiki/index.php/UnRAID_Manual#Replace_a_single_disk_with_a_bigger_one  You must replace a failed disk with a disk which is as big or bigger than the original and not bigger than the parity disk. If the replacement disk is larger than your parity disk, then the system permits a special configuration change called swap-disable. For swap-disable, you use your existing parity disk to replace the failed disk, and you install your new big disk as the parity disk:   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 you start the array, the system will first copy the parity information to the new parity disk, and then reconstruct the contents of the failed disk.
September 6, 200916 yr 6) Assign new SATA disk to disk 3 7) Do a parity check / rebuild (??) It will rebuild the old contents onto the replacement drive when you press "Start" (you might need to check the box under "Start" to enable it). As already mentioned... do NOT press "restore" or you will erase all knowledge of the old disk 3 and the data on it. The array will be on-line during this reconstruction process... It is usually recommended you keep activity at a minimum to allow this to proceed quickly and not introduce complications Also, is it possible to assign my current parity drive as disk 3 and not lose any data?You can, but you must have a parity drive to do any reconstruction. There is a special process to install a larger parity drive and use the existing parity drive as a failed data drive. Basically, it copies the current parity drive (in the failed slot) to the new parity drive and then proceeds to reconstruct the failed drive. It takes about twice as long to recover using this method as it must write two entire disks, but it is necessary if your new disk is larger than the existing parity disk.Â
September 7, 200916 yr Author Fixing this type of thing quickly is a priority!  I'm heading out the door now to buy a new drive :-)  It is unfortunate if you rebooted the server without taking a screenshot and capturing a full syslog. Every time you reboot the syslog is completely refreshed and hints of what caused events like this are lost. All we know at this point is that unRAID removed the disk from the array. The best way to know if the disk is good or bad is to look at its smart report. (For more info. go to the troubleshooting link in my sig and read about smartctl).  I'm running a full slackware install, all the syslog files are rotated so I still have access to them :-)  ls -l /dev/disk/by-id  Unfortunately, the drive doesn't show up here :-(   Opening up the magic syslog shows this:  Aug 31 11:30:24 TANK kernel: hdb: dma_timer_expiry: dma status == 0x61 Aug 31 11:30:34 TANK kernel: hdb: DMA timeout error Aug 31 11:30:34 TANK kernel: hdb: dma timeout error: status=0xd0 { Busy } Aug 31 11:30:34 TANK kernel: ide: failed opcode was: unknown Aug 31 11:31:04 TANK kernel: ide0: reset: master: passed; slave: failed Aug 31 11:31:05 TANK kernel: hdb: status error: status=0x00 { } Aug 31 11:31:35 TANK kernel: end_request: I/O error, dev hdb, sector 401820735 Aug 31 11:31:35 TANK kernel: md: disk3 read error Aug 31 11:31:35 TANK kernel: handle_stripe read error: 401820672/3, count: 1 Aug 31 11:31:36 TANK kernel: end_request: I/O error, dev hdb, sector 401820743 Aug 31 11:31:36 TANK kernel: end_request: I/O error, dev hdb, sector 401820759 Aug 31 11:31:36 TANK kernel: end_request: I/O error, dev hdb, sector 401820767 ^^ repeated hundreds of times  Â
September 7, 200916 yr Unless the cable to the disk became dislodged, I see a new disk drive in your future.   (It is worth a few minutes to power down and check the connections to the old drive)  Right now, your disk is not responding at all.  Joe L.
September 7, 200916 yr It is pretty rare for a drive to suddenly just stop working and "go out" like a lightbulb. I suggest that you power down, check both the data cable and the power cable connections. If you have an extra power connection and an extra data cable, try hooking up both. You could even try a different SATA port. If you still can't see the drive, I'd give up on it and replace it. But if not, you had a cabling problem - by far the most common cause of drive failure! Take a smart report when/if you can. If the drive isn't dead, the smart report will tell you if it is dying.
September 7, 200916 yr Author I feel a little bit silly right about now.  It just occured to me that I had never powered off the server, I had only rebooted it.  I powered down cleanly, and powered back up, and now unraid says:  "Stopped. Disabled disk replaced." (which I haven't yet)  The drive is now visible, but I can see this:  root@TANK:~# smartctl -a -d ata /dev/hdb smartctl version 5.38 [i486-slackware-linux-gnu] Copyright © 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/  === START OF INFORMATION SECTION === Model Family:  Seagate Barracuda 7200.10 family Device Model:  ST3500630A Serial Number:  9QG1TV5X Firmware Version: 3.AAE User Capacity:  500,107,862,016 bytes Device is:    In smartctl database [for details use: -P show] ATA Version is: 7 ATA Standard is: Exact ATA specification draft version not indicated Local Time is:  Mon Sep 7 14:29:48 2009 CST SMART support is: Available - device has SMART capability. SMART support is: Enabled  === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED  General SMART Values: Offline data collection status: (0x82) Offline data collection activity                     was completed without error.                     Auto Offline Data Collection: Enabled. Self-test execution status:   ( 0) The previous self-test routine completed                     without error or no self-test has ever                     been run. Total time to complete Offline data collection:        ( 430) seconds. Offline data collection capabilities:          (0x5b) SMART execute Offline immediate.                     Auto Offline data collection on/off support.                     Suspend Offline collection upon new                     command.                     Offline surface scan supported.                     Self-test supported.                     No Conveyance Self-test supported.                     Selective Self-test supported. SMART capabilities:      (0x0003) Saves SMART data before entering                     power-saving mode.                     Supports SMART auto save timer. Error logging capability:    (0x01) Error logging supported.                     General Purpose Logging supported. Short self-test routine recommended polling time:    ( 1) minutes. Extended self-test routine recommended polling time:    ( 163) minutes.  SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME     FLAG  VALUE WORST THRESH TYPE   UPDATED WHEN_FAILED RAW_VALUE  1 Raw_Read_Error_Rate  0x000f 115 082 006  Pre-fail Always   -   89052350  3 Spin_Up_Time      0x0003 092 092 000  Pre-fail Always   -   0  4 Start_Stop_Count    0x0032 098 098 020  Old_age Always   -   2743  5 Reallocated_Sector_Ct 0x0033 100 100 036  Pre-fail Always   -   6  7 Seek_Error_Rate    0x000f 086 060 030  Pre-fail Always   -   465126290  9 Power_On_Hours     0x0032 084 084 000  Old_age Always   -   14645 10 Spin_Retry_Count    0x0013 100 100 097  Pre-fail Always   -   0 12 Power_Cycle_Count   0x0032 100 100 020  Old_age Always   -   233 187 Reported_Uncorrect   0x0032 100 100 000  Old_age Always   -   0 189 High_Fly_Writes    0x003a 100 100 000  Old_age Always   -   0 190 Airflow_Temperature_Cel 0x0022 061 048 045  Old_age Always   -   39 (Lifetime Min/Max 39/39) 194 Temperature_Celsius  0x0022 039 052 000  Old_age Always   -   39 (0 17 0 0) 195 Hardware_ECC_Recovered 0x001a 090 052 000  Old_age Always   -   80496754 197 Current_Pending_Sector 0x0012 100 100 000  Old_age Always   -   0 198 Offline_Uncorrectable 0x0010 100 100 000  Old_age Offline   -   0 199 UDMA_CRC_Error_Count  0x003e 200 200 000  Old_age Always   -   102 200 Multi_Zone_Error_Rate 0x0000 100 253 000  Old_age Offline   -   0 202 TA_Increase_Count   0x0032 100 253 000  Old_age Always   -   0  SMART Error Log Version: 1 ATA Error Count: 101 (device log contains only the most recent five errors)     CR = Command Register [HEX]     FR = Features Register [HEX]     SC = Sector Count Register [HEX]     SN = Sector Number Register [HEX]     CL = Cylinder Low Register [HEX]     CH = Cylinder High Register [HEX]     DH = Device/Head Register [HEX]     DC = Device Command Register [HEX]     ER = Error register [HEX]     ST = Status register [HEX] Powered_Up_Time is measured from power on, and printed as DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes, SS=sec, and sss=millisec. It "wraps" after 49.710 days.  Error 101 occurred at disk power-on lifetime: 10525 hours (438 days + 13 hours)  When the command that caused the error occurred, the device was active or idle.   After command completion occurred, registers were:  ER ST SC SN CL CH DH  -- -- -- -- -- -- --  84 51 00 00 00 00 e0 Error: ICRC, ABRT at LBA = 0x00000000 = 0   Commands leading to the command that caused the error were:  CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name  -- -- -- -- -- -- -- -- ---------------- --------------------  25 00 08 c7 87 5d e0 00   08:03:17.347 READ DMA EXT  25 00 08 c7 87 5d e0 00   08:03:16.905 READ DMA EXT  10 00 3f 00 00 00 e0 00   08:03:16.905 RECALIBRATE [OBS-4]  25 00 08 c7 87 5d e0 00   08:03:16.463 READ DMA EXT  25 00 08 c7 87 5d e0 00   08:03:16.023 READ DMA EXT  Error 100 occurred at disk power-on lifetime: 10525 hours (438 days + 13 hours)  When the command that caused the error occurred, the device was active or idle.   After command completion occurred, registers were:  ER ST SC SN CL CH DH  -- -- -- -- -- -- --  84 51 00 00 00 00 e0 Error: ICRC, ABRT at LBA = 0x00000000 = 0   Commands leading to the command that caused the error were:  CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name  -- -- -- -- -- -- -- -- ---------------- --------------------  25 00 08 c7 87 5d e0 00   08:03:14.192 READ DMA EXT  10 00 3f 00 00 00 e0 00   08:03:16.905 RECALIBRATE [OBS-4]  25 00 08 c7 87 5d e0 00   08:03:16.905 READ DMA EXT  25 00 08 c7 87 5d e0 00   08:03:16.463 READ DMA EXT  c6 00 10 00 00 00 e0 00   08:03:16.023 SET MULTIPLE MODE  Error 99 occurred at disk power-on lifetime: 10525 hours (438 days + 13 hours)  When the command that caused the error occurred, the device was active or idle.   After command completion occurred, registers were:  ER ST SC SN CL CH DH  -- -- -- -- -- -- --  84 51 00 00 00 00 e0 Error: ICRC, ABRT at LBA = 0x00000000 = 0   Commands leading to the command that caused the error were:  CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name  -- -- -- -- -- -- -- -- ---------------- --------------------  25 00 08 c7 87 5d e0 00   08:03:14.192 READ DMA EXT  25 00 08 c7 87 5d e0 00   08:03:14.172 READ DMA EXT  c6 00 10 00 00 00 e0 00   08:03:14.162 SET MULTIPLE MODE  00 00 40 00 00 00 00 06   08:03:16.463 NOP [Abort queued commands]  ef 03 40 00 00 00 e0 02   08:03:16.023 SET FEATURES [set transfer mode]  Error 98 occurred at disk power-on lifetime: 10525 hours (438 days + 13 hours)  When the command that caused the error occurred, the device was active or idle.   After command completion occurred, registers were:  ER ST SC SN CL CH DH  -- -- -- -- -- -- --  84 51 00 00 00 00 e0 Error: ICRC, ABRT at LBA = 0x00000000 = 0   Commands leading to the command that caused the error were:  CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name  -- -- -- -- -- -- -- -- ---------------- --------------------  25 00 08 c7 87 5d e0 00   08:03:14.192 READ DMA EXT  c6 00 10 00 00 00 e0 00   08:03:14.172 SET MULTIPLE MODE  00 00 40 00 00 00 00 06   08:03:14.162 NOP [Abort queued commands]  ef 03 40 00 00 00 e0 02   08:03:14.152 SET FEATURES [set transfer mode]  25 00 08 c7 87 5d e0 00   08:03:16.023 READ DMA EXT  Error 97 occurred at disk power-on lifetime: 10525 hours (438 days + 13 hours)  When the command that caused the error occurred, the device was active or idle.   After command completion occurred, registers were:  ER ST SC SN CL CH DH  -- -- -- -- -- -- --  84 51 00 00 00 00 e0 Error: ICRC, ABRT at LBA = 0x00000000 = 0   Commands leading to the command that caused the error were:  CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name  -- -- -- -- -- -- -- -- ---------------- --------------------  25 00 08 c7 87 5d e0 00   08:03:14.192 READ DMA EXT  25 00 08 c7 87 5d e0 00   08:03:14.172 READ DMA EXT  10 00 3f 00 00 00 e0 00   08:03:14.162 RECALIBRATE [OBS-4]  25 00 08 c7 87 5d e0 00   08:03:14.152 READ DMA EXT  25 00 08 c7 87 5d e0 00   08:03:14.141 READ DMA EXT  SMART Self-test log structure revision number 1 Num Test_Description  Status         Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline  Completed without error   00%  12818    - # 2 Short offline   Completed without error   00%  10432    -  SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS   1    0    0 Not_testing   2    0    0 Not_testing   3    0    0 Not_testing   4    0    0 Not_testing   5    0    0 Not_testing Selective self-test flags (0x0):  After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay.  Is it worth replacing it?
September 7, 200916 yr Author nb: SMART errors were from an older issue (bad cable):  http://lime-technology.com/forum/index.php?topic=3021.0  If I'm right, it only shows errors at 438 days but it has been powered on for 610 days. Hoping someone can diagnose the smart report before I press the 'rebuild' option  Cheers
September 7, 200916 yr First I'll respond on the reason that unRAID is saying the disabled disk has been replaced. Based on the screenshot previously posted, you rebooted at a time when unRAID could not see the suspect drive. When this happens, unRAID basically "forgets" about the old drive, yet continues to simulate its contents. When the disk is again recognized (in the same physical port as before), unRAID sees it as a new disk and offers to rebuild onto it.  Second, your drive looks okay. There are 6 reallocated sectors. I'd keep an eye on this stat. If after every parity check this number is increasing, I'd look to replace the drive. But a drive with 6 reallocated sectors is no problem at all if it holds steady. I am not as familiar with the types of UDMA errors being reported. As you say, it was many power-on hours ago. But it is also possible that you have just not been accessing the drive for over a week. It is not unusual, with a bad data cable, to get log errors about attempts to access invalid sectors. It is one of the things that helps me determine that cabling is a problem. But again, I am not as familiar with whether the UDMA errors fall in that category or not, but it would be my opinion (until proven otherwise) that these errors are cabling related.  I'd probably run a smartctl long test on the drive as a final check to see what it has to say. This type of test does not utilize the data cable at all, and if it finding errors, they are real drive errors. But if it is clean, I'd have even more confidence in the drive. (Follow the troubleshooting link in my sig for instructions on running the long smart test).  You have a number of options on how to proceed. The best one depends.  1. If you have not written to the array since the drive was disabled, you should consider the "trust my parity" procedure (look in the FAQ for the link). It will put the disk back into the array and then check to make sure parity is valid. I'd likely STOP the automatic parity check immediately, and then initiate a read-only parity check (see link here). A few parity errors would not be unexpected, especially early in the check process. But if you are getting a ton of parity check issues when you know you have not written to the array, especially if you are seeing more errors in the smartctl report, that would indicate that the drive is failing. The read-only parity check would mean that parity would not be updated allowing you to rebuild the disk later without being corrupted by this attempt with the old disk. If the read-only parity check finishes with minimal parity errors (excluding those found in the first minute), you'd need to run another parity check (not read-only) to correct them.  2. If you have a spare disk that you wanted to add to the array anyway, you could install it to the machine, assign the new disk to the old slot, and allow unRAID to rebuild onto the new disk. Leave the existing disk unassigned to a disk slot. The benefit here is that if anything goes horribly wrong during the rebuild, you still have the original disk which likely contains your data and can be used for recovery. You can add the suspect drive to the array if desired after the array is healthy again.  3. A third option is to allow it to rebuild onto the original disk (as it wants to do). This is actually the Limetech recommended method and has been used previously many times. There is an element of risk slightly higher than the above methods, but it is straightforward, tried, and true.
September 7, 200916 yr Author Absolutely fantastic response, thanks bjp999. Â I decided to rebuild onto the original drive and your theory does make sense. I'm confident that the errors are from a long time ago and not from recently. As I now recall from the logs, this issue started around the same day we had many power failures - each time a parity check was in place. It has taught me to check the unraid page more often though - if it wasn't for the weird network issues, I probably would have noticed for a few more days (which is scary if I had another failure!) Â I actually do a parity check at least 2-3 times per month, so I'm confident there isn't any *real* issues. Â The rebuild has now finished, and this is the results: Â Last checked on 9/7/2009 7:52:08 PM, finding 0 errors.) Â I went out and bought a 1TB drive to replace it anyway, so I'm going to add that to the array as I was running out of free space! Â I'll run a long test now. Â Â
September 8, 200916 yr You didn't check the cables and still don't know why the drive was taken out of service? Â I believe the UDMA errors could be cables. I have one SATA drive that shows a high number after I had a cable problem. Â Peter Â
September 8, 200916 yr Author You didn't check the cables and still don't know why the drive was taken out of service?  I believe the UDMA errors could be cables. I have one SATA drive that shows a high number after I had a cable problem.  Peter   Hi Peter,  No, I didn't check the cables. The UDMA errors were from a long time ago (see http://lime-technology.com/forum/index.php?topic=3021.0 where the count is exactly the same). I believe the drive was taken out of service because of the multiple power failures and my laziness in checking the management page afterwards as this was around the same time as the problem began.  According to the syslogs, it actually started directly after a reboot - not in the middle of a 'powered up session' (if that makes sense).   Cheers  Edit: The 'long' S.M.A.R.T. test passed without any errors.  Â
July 29, 201015 yr disk3 device: pci-0000:06:00.1-ide-0:1 (no device)  Going from "http://lime-technology.com/forum/index.php?topic=2601.msg21033#msg21033"  "Unraid will simulate a failed disk"  Would that be the reason I can still access all of my shares?   Yup.   Before tonight I had no idea that my failed "disk2" would still be accessible as a disk share.  It was a 2TB WD EADS drive that I bought just a few weeks ago, and for some reason it's throwing errors galore.  I tried changing SATA cables, taking the drive out of the hot-swap cage and connecting it with new cables, anything I could think of that might lead me to a solution... but it turns out it's the drive, not the interconnecting hardware.  So I removed it, restarted UnRAID and copied everything from my "disk2" share over to other drives in my array.  This wasn't as painful as it may sound because I only had a dozen GB of stuff on it since it was so error-prone.  It worked like a charm.  I am currently rebuilding my array with a 750GB drive in the old 2TB drive's place since I don't have another 2TB drive handy... the "Restore" button comes in handy for this, which is one reason I never upgraded to a newer version of UnRAID yet - I like the functionality of the Restore button, although no one likes the nomenclature.  Importantly, I was only safe using the Restore button because I had already copied the data from my "missing" disk2 to other drives in the array. As others have said, don't go pressing it if you don't know what it will do. Â
July 29, 201015 yr disk3 device: pci-0000:06:00.1-ide-0:1 (no device)  Going from "http://lime-technology.com/forum/index.php?topic=2601.msg21033#msg21033"  "Unraid will simulate a failed disk"  Would that be the reason I can still access all of my shares?   Yup.   Before tonight I had no idea that my failed "disk2" would still be accessible as a disk share.  It was a 2TB WD EADS drive that I bought just a few weeks ago, and for some reason it's throwing errors galore.  I tried changing SATA cables, taking the drive out of the hot-swap cage and connecting it with new cables, anything I could think of that might lead me to a solution... but it turns out it's the drive, not the interconnecting hardware.  So I removed it, restarted UnRAID and copied everything from my "disk2" share over to other drives in my array.  This wasn't as painful as it may sound because I only had a dozen GB of stuff on it since it was so error-prone.  It worked like a charm.  I am currently rebuilding my array with a 750GB drive in the old 2TB drive's place since I don't have another 2TB drive handy... the "Restore" button comes in handy for this, which is one reason I never upgraded to a newer version of UnRAID yet - I like the functionality of the Restore button, although no one likes the nomenclature.  Importantly, I was only safe using the Restore button because I had already copied the data from my "missing" disk2 to other drives in the array. As others have said, don't go pressing it if you don't know what it will do.  You can upgrade with peace of mind. The button has been removed in recent versions, but its exact equivalent was put into place as the initconfig command. You did not "restore" your data, you "Initialized a New Disk Configuration and Immediately Invalidated Parity based on any Prior Configuration" You copied your data to a working disk, replaced the old larger disk with a smaller one and then asked unRAID to Initialize a new disk configuration. The functionality was not removed, only the VERY misleading name (and the button that too easy for less experienced unRAID owners to press in situations when it should not be pressed)
January 3, 201115 yr You can upgrade with peace of mind.  The button has been removed in recent versions, but its exact equivalent was put into place as the initconfig command. You did not "restore" your data, you "Initialized a New Disk Configuration and Immediately Invalidated Parity based on any Prior Configuration" You copied your data to a working disk, replaced the old larger disk with a smaller one and then asked unRAID to Initialize a new disk configuration.  The functionality was not removed, only the VERY misleading name (and the button that too easy for less experienced unRAID owners to press in situations when it should not be pressed)  Too true - there was no "restoration" involved - but the button is so handy and it's not that I use it enough to remember "init config".  No argument on the nomenclature... the button should have been renamed "Init Config" and have lots of red text warnings pop up with an "Are You Sure?" prompt.... but it still should exist as a button... it's (supposed to be) a GUI  Power users like buttons, too.
Archived
This topic is now archived and is closed to further replies.