April 23, 201016 yr Hi guys, new to unRaid and these forums, just got everything working last few days. here is my situation i would appreciate some guidance. ive been migrating from Windows home server to my unraid box and had to copy a disk, remove from whs, move it into unraid box, then move to the next disk etc. i have a bunch of 1.5 and 1 tb drives. i got all my disks moved over to unraid box, and left a 1.5 tb for last be my parity, all my data is copied to the unraid box already. but when i went to assign the parity drive, it is a few bytes smaller than my largest data drive. unfortunately i didnt know some 1.5tb drives could be slightly smaller than others, but they are, so there you go. i will be using my current disk2 to be the parity drive once i move the data off it. so what im currently thinking/doing is assign the drive i was going to use as parity to disk8. i then changed the shares' properties that currently reside on disk2 to include disk8, i then copied a dummy file over to each share so that it would create the respective share folder on disk8. what i want to know is if it is as simple as just copying all the data from disk2 to disk8, then reassign disk2 to parity and everything will be ok? and also, im currently using a windows 7 machine to copy from disk2 to disk8 over the network (browse to network share \\tower\disk2, copy all, then browse to disk8 and paste), is there a faster way to do it, as i have been copying data for 6 days and would like to start using this unraid server. lastly, unraid is the first time i have touched anything linux, but ive been working with PC's and windows for years. any help is greatly appreciated so i can get started on fixing my mess as im not protected by parity at all at the moment. thanx
April 23, 201016 yr Hi guys, new to unRaid and these forums, just got everything working last few days. here is my situation i would appreciate some guidance. ive been migrating from Windows home server to my unraid box and had to copy a disk, remove from whs, move it into unraid box, then move to the next disk etc. i have a bunch of 1.5 and 1 tb drives. i got all my disks moved over to unraid box, and left a 1.5 tb for last be my parity, all my data is copied to the unraid box already. but when i went to assign the parity drive, it is a few bytes smaller than my largest data drive. unfortunately i didnt know some 1.5tb drives could be slightly smaller than others, but they are, so there you go. i will be using my current disk2 to be the parity drive once i move the data off it. so what im currently thinking/doing is assign the drive i was going to use as parity to disk8. i then changed the shares' properties that currently reside on disk2 to include disk8, i then copied a dummy file over to each share so that it would create the respective share folder on disk8. what i want to know is if it is as simple as just copying all the data from disk2 to disk8, then reassign disk2 to parity and everything will be ok? and also, im currently using a windows 7 machine to copy from disk2 to disk8 over the network (browse to network share \\tower\disk2, copy all, then browse to disk8 and paste), is there a faster way to do it, as i have been copying data for 6 days and would like to start using this unraid server. lastly, unraid is the first time i have touched anything linux, but ive been working with PC's and windows for years. any help is greatly appreciated so i can get started on fixing my mess as im not protected by parity at all at the moment. thanx You have a bigger underlying issue. You probably have a HPA (Host Protected Area) on the disk you were intending to use as a parity disk. I say this because all 1.5TB disks I am aware of have the exact same size unless an HPA has been created to artificially make it look smaller. Do you have a GigaByte Motherboard? (Somehow, I bet you do... or, the disk you were planning to use was attached to a GigaByte board at one time in its life.) There is good news though... First, disable the HPA "feature" if you are using a GigaByte MB, otherwise, the BIOS will do the EXACT SAME THING no matter what disk you use. Then we can remove the HPA so you can use the disk you intended. Post a syslog and we can give you the exact command. (instructions in the wiki under Troubleshooting) To remove the HPA, follow the basic guide here: http://lime-technology.com/forum/index.php?topic=3739.msg48787#msg48787 Joe L.
April 23, 201016 yr Author Joe, yes it has been in a gigabyte board, and still is, 965p-ds3p. i have 5 1.5 tb seagate drives, bought over a few years, although 2 of them brand new bought few days ago, these report as bigger than the others. i will look into the gigabyte MB bios now and look for the HPA feature to disable it. i will then look into the how i obtain the syslog and post it and go from there. will reply shortly. thanx
April 23, 201016 yr Joe, yes it has been in a gigabyte board, and still is, 965p-ds3p. i have 5 1.5 tb seagate drives, bought over a few years, although 2 of them brand new bought few days ago, these report as bigger than the others. i will look into the gigabyte MB bios now and look for the HPA feature to disable it. i will then look into the how i obtain the syslog and post it and go from there. will reply shortly. thanx There is a huge amount of information on how to disable the HPA in the wiki (on some MB you cannot) It is labeled in the BIOS as a way to copy the BIOS to the disk for recovery purposes, don't expect it to mention an "HPA" See here in the wiki: http://lime-technology.com/wiki/index.php?title=UnRAID_Topical_Index#HPA You might need to update your BIOS. If you think you are safe since there is already an HPA on one of your disks, think again.. See here for what will eventually happen to your array: http://lime-technology.com/forum/index.php?topic=5820.msg54982#msg54982 Note: even if you disable the HPA feature in the BIOS, when your CMOS battery eventually dies, the HPA feature will enable itself if it is the "default". That will basically not be fun. It will either clobber your data, or clobber your parity drive... (depending on which drive it decides to use) Some users have completely replaced their MB because they did not want to risk certain eventual trashing of their disks. Joe L.
April 23, 201016 yr Author ok, i cant find an HPA disable feature, and after doing quick search on the forums, some GB boards dont. im currently checking the bios to see if its upgradable. i can upgrade to one later version, doesnt mention HPA though. im starting to get a real sick feeling about this now. especially after reading about some of your older posts regarding this HPA. will report back after i flash the bios.
April 23, 201016 yr HPA is also known as 'Virtual Dual BIOS' or has been also known as 'Write BIOS Image to HDD' as well. I would look at all avenues in your BIOS menu's to see any of the three mentioned options in your BIOS and make sure it is Disabled! I believe that most of the Gigabyte mobo BIOS updates that are released now are making this feature disabled by default, both of my recent GIgabyte boards that I purchased with no BIOS updates had this option enabled by default. I've now moved on to a Asus board for my unraid server to avoid this problem all together. Like what Joe L said, it has caused heartache for a particular member and for that to happen, Ive taken this seriously and have changed my board. ok, i cant find an HPA disable feature, and after doing quick search on the forums, some GB boards dont. im currently checking the bios to see if its upgradable. i can upgrade to one later version, doesnt mention HPA though. im starting to get a real sick feeling about this now. especially after reading about some of your older posts regarding this HPA. will report back after i flash the bios.
April 23, 201016 yr ok, i cant find an HPA disable feature, and after doing quick search on the forums, some GB boards dont. im currently checking the bios to see if its upgradable. i can upgrade to one later version, doesnt mention HPA though. im starting to get a real sick feeling about this now. especially after reading about some of your older posts regarding this HPA. will report back after i flash the bios. The BIOS will probably call the feature "Xpress BIOS Rescue" or "Virtual Dual BIOS" or "Express BIOS Rescue function" It will not mention HPA. It might be on a "hidden-menu" accessible only after pressing a special key sequence to get to "advanced features" Gigabyte often uses Shift-F1 to get more BIOS options.
April 23, 201016 yr Author ok, bios updated to f7 and found the feature and it was disabled by default after flashing which is good news. not sure how to proceed (more not confident), the disk i want to use as parity is currently assigned to disk8. which part of the syslog is required to determine the exact command i need to run? and im guessing i should remove HPA on every drive that has it?
April 23, 201016 yr Author ok here s a section from my latest syslog where HPA is mentioned: Apr 23 10:52:33 Tower kernel: ata5.00: ATA-8: ST31500341AS, CC1H, max UDMA/133 Apr 23 10:52:33 Tower kernel: ata5.00: 2930277168 sectors, multi 16: LBA48 NCQ (depth 0/32) Apr 23 10:52:33 Tower kernel: ata6.00: HPA detected: current 2930275055, native 2930277168 Apr 23 10:52:33 Tower kernel: ata6.00: ATA-8: ST31500341AS, CC1H, max UDMA/133 Apr 23 10:52:33 Tower kernel: ata6.00: 2930275055 sectors, multi 16: LBA48 NCQ (depth 0/32) Apr 23 10:52:33 Tower kernel: ata5.00: configured for UDMA/133 Apr 23 10:52:33 Tower kernel: ata6.00: configured for UDMA/133 Apr 23 10:52:33 Tower kernel: ata4.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Apr 23 10:52:33 Tower kernel: ata4.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Apr 23 10:52:33 Tower kernel: ata3.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Apr 23 10:52:33 Tower kernel: ata3.01: SATA link up 1.5 Gbps (SStatus 113 SControl 300) Apr 23 10:52:33 Tower kernel: ata3.00: HPA detected: current 2930275055, native 2930277168 Apr 23 10:52:33 Tower kernel: ata3.00: ATA-8: ST31500341AS, CC1H, max UDMA/133 Apr 23 10:52:33 Tower kernel: ata3.00: 2930275055 sectors, multi 16: LBA48 NCQ (depth 0/32) Apr 23 10:52:33 Tower kernel: ata4.00: ATA-8: ST31500341AS, CC1H, max UDMA/133 Apr 23 10:52:33 Tower kernel: ata4.00: 2930277168 sectors, multi 16: LBA48 NCQ (depth 0/32) Apr 23 10:52:33 Tower kernel: ata3.01: ATA-8: ST31000340AS, SD15, max UDMA/133 Apr 23 10:52:33 Tower kernel: ata3.01: 1953525168 sectors, multi 16: LBA48 NCQ (depth 0/32) Apr 23 10:52:33 Tower kernel: ata4.01: ATA-8: ST31500341AS, CC1H, max UDMA/133 Apr 23 10:52:33 Tower kernel: ata4.01: 2930277168 sectors, multi 16: LBA48 NCQ (depth 0/32) Apr 23 10:52:33 Tower kernel: ata4.00: configured for UDMA/133 Apr 23 10:52:33 Tower kernel: ata3.00: configured for UDMA/133 Apr 23 10:52:33 Tower kernel: ata3.01: configured for UDMA/133 Apr 23 10:52:33 Tower kernel: scsi 5:0:0:0: Direct-Access ATA ST31500341AS CC1H PQ: 0 ANSI: 5 Apr 23 10:52:33 Tower kernel: scsi 5:0:1:0: Direct-Access ATA ST31000340AS SD15 PQ: 0 ANSI: 5 wasnt sure how much to copy and paste, and i did find 3 instances of HPA detected in the syslog. i have been reading this thread: http://lime-technology.com/forum/index.php?topic=5072.msg46903#msg46903 but that syslog looks different to mine as mine doesnt mention the serial number of the drive that HPA is detected on. how do i tell which drive is which? HPA is detected on ATA 2, 3 and 6....
April 23, 201016 yr ok here s a section from my latest syslog where HPA is mentioned: Apr 23 10:52:33 Tower kernel: ata5.00: ATA-8: ST31500341AS, CC1H, max UDMA/133 Apr 23 10:52:33 Tower kernel: ata5.00: 2930277168 sectors, multi 16: LBA48 NCQ (depth 0/32) Apr 23 10:52:33 Tower kernel: ata6.00: HPA detected: current 2930275055, native 2930277168 Apr 23 10:52:33 Tower kernel: ata6.00: ATA-8: ST31500341AS, CC1H, max UDMA/133 Apr 23 10:52:33 Tower kernel: ata6.00: 2930275055 sectors, multi 16: LBA48 NCQ (depth 0/32) Apr 23 10:52:33 Tower kernel: ata5.00: configured for UDMA/133 Apr 23 10:52:33 Tower kernel: ata6.00: configured for UDMA/133 Apr 23 10:52:33 Tower kernel: ata4.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Apr 23 10:52:33 Tower kernel: ata4.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Apr 23 10:52:33 Tower kernel: ata3.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Apr 23 10:52:33 Tower kernel: ata3.01: SATA link up 1.5 Gbps (SStatus 113 SControl 300) Apr 23 10:52:33 Tower kernel: ata3.00: HPA detected: current 2930275055, native 2930277168 Apr 23 10:52:33 Tower kernel: ata3.00: ATA-8: ST31500341AS, CC1H, max UDMA/133 Apr 23 10:52:33 Tower kernel: ata3.00: 2930275055 sectors, multi 16: LBA48 NCQ (depth 0/32) Apr 23 10:52:33 Tower kernel: ata4.00: ATA-8: ST31500341AS, CC1H, max UDMA/133 Apr 23 10:52:33 Tower kernel: ata4.00: 2930277168 sectors, multi 16: LBA48 NCQ (depth 0/32) Apr 23 10:52:33 Tower kernel: ata3.01: ATA-8: ST31000340AS, SD15, max UDMA/133 Apr 23 10:52:33 Tower kernel: ata3.01: 1953525168 sectors, multi 16: LBA48 NCQ (depth 0/32) Apr 23 10:52:33 Tower kernel: ata4.01: ATA-8: ST31500341AS, CC1H, max UDMA/133 Apr 23 10:52:33 Tower kernel: ata4.01: 2930277168 sectors, multi 16: LBA48 NCQ (depth 0/32) Apr 23 10:52:33 Tower kernel: ata4.00: configured for UDMA/133 Apr 23 10:52:33 Tower kernel: ata3.00: configured for UDMA/133 Apr 23 10:52:33 Tower kernel: ata3.01: configured for UDMA/133 Apr 23 10:52:33 Tower kernel: scsi 5:0:0:0: Direct-Access ATA ST31500341AS CC1H PQ: 0 ANSI: 5 Apr 23 10:52:33 Tower kernel: scsi 5:0:1:0: Direct-Access ATA ST31000340AS SD15 PQ: 0 ANSI: 5 wasnt sure how much to copy and paste, and i did find 3 instances of HPA detected in the syslog. i have been reading this thread: http://lime-technology.com/forum/index.php?topic=5072.msg46903#msg46903 but that syslog looks different to mine as mine doesnt mention the serial number of the drive that HPA is detected on. how do i tell which drive is which? HPA is detected on ATA 2, 3 and 6.... Post the full syslog. You can get it on recent versions of unRAID by putting //tower/log/syslog in your browser. Then, zip up the result, and attach it to your next post.
April 23, 201016 yr Author OK, after some reading, i pulled the drive out and connected to another pc, ran seatools, set capacity to max and put it back into unraid, everything looks good. so, out of this experience i see that 2 other drives also have HPA enabled, if i do the same process for those 2 drives, will i loose any data as the other 2 drives are full? is there anything else i should be aware of before i proceed? want to get started to start building my parity drive. all of you guys' help is greatly appreciated.... thanx
April 23, 201016 yr OK, after some reading, i pulled the drive out and connected to another pc, ran seatools, set capacity to max and put it back into unraid, everything looks good. so, out of this experience i see that 2 other drives also have HPA enabled, if i do the same process for those 2 drives, will i loose any data as the other 2 drives are full? is there anything else i should be aware of before i proceed? want to get started to start building my parity drive. all of you guys' help is greatly appreciated.... thanx It is far more complicated for the data drives. If you change the size unRAID will think it is a different disk. If you do one at a time you might be ok. unRAID will want to re-construct the old contents onto the "new" replacement. Whatever you do, do not press the button labeled "Restore" as it has nothing to do with Reconstruction of data. Just press "Start" to begin the re-construction process after removing the HPA. Make sure you only do one drive at a time, otherwise no re-construction is possible because unRAID will think multiple disks have been changed.
April 23, 201016 yr Lets look at this another way. You have yet to use the parity disk so unRAID should basically care less if the disk size changed or not. I would do this; Remove one data disk and fix it and reinstall it. Press restore to get the array running again. If all is well then do the other data disk. Once both data disks are fixed then assign parity and let it build parity. However, if you lack any confidence that the HPA can successfully be removed on a data disk without damaging the data then use the second option. The second option goes something like this; Build parity. Run a parity check and ensure there are no errors. Remove, fix and replace one data disk. Check the "I'm sure" box under the start button and start the array which will rebuild the disk. repeat the last 3 steps for the next data disk. Peter
April 23, 201016 yr Lets look at this another way. You have yet to use the parity disk so unRAID should basically care less if the disk size changed or not. I would do this; Remove one data disk and fix it and reinstall it. Press restore to get the array running again. If all is well then do the other data disk. Once both data disks are fixed then assign parity and let it build parity. However, if you lack any confidence that the HPA can successfully be removed on a data disk without damaging the data then use the second option. The second option goes something like this; Build parity. Run a parity check and ensure there are no errors. Remove, fix and replace one data disk. Check the "I'm sure" box under the start button and start the array which will rebuild the disk. repeat the last 3 steps for the next data disk. Peter I don't think to fix this without installing parity is best UNLESS you have no data on the data disks, since using your procedure will cause the (apparent) data disk size to change. That will cause unRAID to see the partition is not using the entire disk. That will cause unRAID to think it is a foreign disk and it will want to clear it if you start the array. After clearing it (erasing any possibility to get any of your data), it will present to you a "Format" button to allow you to Format it. So, fixing the HPA with no parity disk installed will cause unRAID think it is a brand new disk, with NO native unRAID data, all because the partition is wrongly sized for the total available size. If you already have the data drives loaded, and no backup elsewhere, put the parity drive into place BEFORE you fix the HPA on the data disks. If however, you do install the parity drive first, then you can Stop the array Fix the HPA on one data disk Start the array by pressing "Start" The array will think you replaced the old drive with a new since the size is different (and slightly larger). It will first expand the partition to use the full size of the disk, then it will expand the file-system to use the full partition, then it will re-construct the data from parity and the other data disks onto the newly fixed drive. Once unRAID has re-constructed the disk, and you have parity protection once more, then you can do the same with the next data disk with an HPA to be removed. Whatever you do, once you assign a parity drive, and are in the process of re-building onto the newly fixed drive, do not press the button labeled as "restore" as it is actually a "Delete Disk Configuration and Parity" button. You need the parity to reconstruct the drive you removed the HPA from, and do not want to delete it. Joe L.
April 24, 201016 yr Author ok, i have since removed HPA on 3 drives it was detected on, one at a time using seatools. When i put it back in to the array, they detected as diferent sizes, i hit restore, and it was fine, no data lost. i did the same for the other 2, also fine, no data loss and array started correctly. i also took the opportunity to update the firmware on 3 drives, 1 of which also had HPA. once everything was put back in, and all green lights showing, i assigned the drive i wanted to build the parity and left it over night to build parity. just got to the server now and parity built ok however disk3 shows 2896 errors and shows this is unmenu: Array Status STARTED, 8 disks in array. Parity is Valid:. Last parity check < 1 day ago . Parity updated 2896 times to address sync errors. Do i have anything to worry about now or are these errors that were detected during the parity sync and have been since resolved? thanks to all of you that are helping, im learning alot about unRaid.
April 24, 201016 yr Author also, this is what i have in syslog, the errors, dont know what they mean though: Apr 23 21:37:13 Tower kernel: handle_stripe read error: 1608979328/3, count: 1 Apr 23 21:37:13 Tower kernel: md: disk3 read error Apr 23 21:37:13 Tower kernel: handle_stripe read error: 1608979336/3, count: 1 Apr 23 21:37:13 Tower kernel: md: disk3 read error Apr 23 21:37:13 Tower kernel: handle_stripe read error: 1608979344/3, count: 1 Apr 23 21:37:16 Tower kernel: ata3.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Apr 23 21:37:16 Tower kernel: ata3.01: failed command: READ DMA EXT Apr 23 21:37:16 Tower kernel: ata3.01: cmd 25/00:00:d7:1d:e7/00:04:5f:00:00/f0 tag 0 dma 524288 in Apr 23 21:37:16 Tower kernel: res 51/40:00:b3:1e:e7/40:00:5f:00:00/10 Emask 0x9 (media error) Apr 23 21:37:16 Tower kernel: ata3.01: status: { DRDY ERR } Apr 23 21:37:16 Tower kernel: ata3.01: error: { UNC } Apr 23 21:37:16 Tower kernel: ata3.00: configured for UDMA/133 Apr 23 21:37:16 Tower kernel: ata3.01: configured for UDMA/133 Apr 23 21:37:16 Tower kernel: ata3: EH complete Apr 23 21:37:19 Tower kernel: ata3.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Apr 23 21:37:19 Tower kernel: ata3.01: failed command: READ DMA EXT Apr 23 21:37:19 Tower kernel: ata3.01: cmd 25/00:00:d7:1d:e7/00:04:5f:00:00/f0 tag 0 dma 524288 in
April 24, 201016 yr ok, i have since removed HPA on 3 drives it was detected on, one at a time using seatools. When i put it back in to the array, they detected as diferent sizes, i hit restore, and it was fine, no data lost. i did the same for the other 2, also fine, no data loss and array started correctly. i also took the opportunity to update the firmware on 3 drives, 1 of which also had HPA. once everything was put back in, and all green lights showing, i assigned the drive i wanted to build the parity and left it over night to build parity. just got to the server now and parity built ok however disk3 shows 2896 errors and shows this is unmenu: Array Status STARTED, 8 disks in array. Parity is Valid:. Last parity check < 1 day ago . Parity updated 2896 times to address sync errors. Do i have anything to worry about now or are these errors that were detected during the parity sync and have been since resolved? thanks to all of you that are helping, im learning alot about unRaid. Parity has already been corrected by the time you see that message. I guess you decided to not follow my instructions. do not press the button labeled as "restore" as it is actually a "Delete Disk Configuration and Parity" button. You need the parity to reconstruct the drive you removed the HPA from, and do not want to delete it. You removed the HPA, but probably did not re-size the file-system in the partition. I hope it works as expected. Probably will, it just might leave that space previously occupied by the HPA as unused. The instructions I gave would have re-sized everything... exactly as if you had upgraded the drive to a bigger size. Joe L.
April 24, 201016 yr also, this is what i have in syslog, the errors, dont know what they mean though: Apr 23 21:37:13 Tower kernel: handle_stripe read error: 1608979328/3, count: 1 Apr 23 21:37:13 Tower kernel: md: disk3 read error Apr 23 21:37:13 Tower kernel: handle_stripe read error: 1608979336/3, count: 1 Apr 23 21:37:13 Tower kernel: md: disk3 read error Apr 23 21:37:13 Tower kernel: handle_stripe read error: 1608979344/3, count: 1 Apr 23 21:37:16 Tower kernel: ata3.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Apr 23 21:37:16 Tower kernel: ata3.01: failed command: READ DMA EXT Apr 23 21:37:16 Tower kernel: ata3.01: cmd 25/00:00:d7:1d:e7/00:04:5f:00:00/f0 tag 0 dma 524288 in Apr 23 21:37:16 Tower kernel: res 51/40:00:b3:1e:e7/40:00:5f:00:00/10 Emask 0x9 (media error) Apr 23 21:37:16 Tower kernel: ata3.01: status: { DRDY ERR } Apr 23 21:37:16 Tower kernel: ata3.01: error: { UNC } Apr 23 21:37:16 Tower kernel: ata3.00: configured for UDMA/133 Apr 23 21:37:16 Tower kernel: ata3.01: configured for UDMA/133 Apr 23 21:37:16 Tower kernel: ata3: EH complete Apr 23 21:37:19 Tower kernel: ata3.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Apr 23 21:37:19 Tower kernel: ata3.01: failed command: READ DMA EXT Apr 23 21:37:19 Tower kernel: ata3.01: cmd 25/00:00:d7:1d:e7/00:04:5f:00:00/f0 tag 0 dma 524288 in A media error is a bad sector on a disk. You;ll probably see it as a re-allocated sector on a smart report, or a sector pending re-allocation, waiting for a subsequent write. Joe L.
April 24, 201016 yr Author Ok Joe, thanx for that, i actually performed what i done before you mentioned not to press restore, otherwise i would have taken your advise. so for now, i assume everything is ok and i can start using it the way properly? i'll be reading up on the forums to familarise myself better with potential issues but i never would have thought of that HPA thing without you saying something, i was about ready to go out and buy a 2 tb drive to ensure it was my largest parity drive.
April 24, 201016 yr Ok Joe, thanx for that, i actually performed what i done before you mentioned not to press restore, otherwise i would have taken your advise. so for now, i assume everything is ok and i can start using it the way properly? i'll be reading up on the forums to familarise myself better with potential issues but i never would have thought of that HPA thing without you saying something, i was about ready to go out and buy a 2 tb drive to ensure it was my largest parity drive. Glad you are up and running. Basically, never use the button labeled as "restore" It is actually a "Delete Disk Configuration and Parity" button. It immediately invalidates parity and the next time you start the array after pressing "restore" it will perform a full parity calculation. Pressing the button labeled as "restore" when you have a failed drive will basically invalidate the parity needed to reconstruct its contents. You'll probably lose the data on the drive. Always use "Start" to start the array unless you are removing a data drive and do not intend to replace it. (there is an exception to this, but it involves other command line commands in conjunction with its use) Joe L.
Archived
This topic is now archived and is closed to further replies.