November 26, 201015 yr Author I did the --rebuild-tree -S , but I had to do it on the /dev/sdc, as it's unmountable. I have tried to mount it manually, but it complains about missing superblock. Parts of the console output is attached. It appears nothing is rebuilt or found. Maybe what I need to do now is to find a dedicated recovery tool, like the ones mentioned in the thread linked by Joe L., and dedicate a seperate machine to deal with the recovery process. Unless of course it will be confirmed, that the disk is actually overwritten during the original swap-disable procedure. While trying to recover these data, I am now considering a Plan B. See next post. putty-tower-2010-11-26.zip
November 26, 201015 yr Author I am now considering plan B, which is more like a complete rebuild/reorganisation, but conserving the remaining data: - I take the problematic disk1 out of the server for treatment on a separate machine like descrived above - I put my other precleared 2TB disk in as disk1 - I reinstall and assign the original disk6, that was the one to be swap-replaced with the old parity drive. It should still (I strongly assume) have its data intact Here I would be able to start the array and build new parity(?), but I would like to go further - all of the steps below without any active parity yet - disk-to-disk copy only: - copy the data from the 400GB PATA-disk originally intended for replacement to the new 2TB disk, to be able to retire it - copy the contents of one of the other 400GB SATA drives to the 2TB disk to retire it - replace the 400GB SATA drive with the 1TB disk that was originally the parity drive (after it is precleared) - Configure the array by assigning relevant disks - Rebuild parity Key question: Will this preserve my data, and after parity rebuild, I'm back in smooth protected waters? I'm actually more or less assuming here, that the data on the individual disks can be found and used independently of unRAID. If yes, then what will be the best method for actually performing the data migration? I will of course preserve the retired drives until I have absolute confirmation that my data are intact in their new location.
November 26, 201015 yr I did the --rebuild-tree -S , but I had to do it on the /dev/sdc, as it's unmountable. I have tried to mount it manually, but it complains about missing superblock. Parts of the console output is attached. It appears nothing is rebuilt or found. Maybe what I need to do now is to find a dedicated recovery tool, like the ones mentioned in the thread linked by Joe L., and dedicate a seperate machine to deal with the recovery process. Unless of course it will be confirmed, that the disk is actually overwritten during the original swap-disable procedure. While trying to recover these data, I am now considering a Plan B. See next post. It is complaining because you would need to use the first partition of sdc. (/dev/sdc1) Note the trailing "1" on the device name. /dev/sdc1 would have the superblock. Joe L.
November 26, 201015 yr Author <DOH> Ain't I a Linux wiz ... That did mount the drive - and I do see some data using MC (still not any of the photos I would have liked to). But I'm a little unsure about what was on disk6 and what on diak1, so maybe most of what I do not see here is on my old sleeping disk6. Now I need to share my newly mounted /dev/sdc1 on the net so I can copy stuff from it - how is that accomplished? I mounted it to a folder like this: mount /dev/sdc1 /dev/nia
November 26, 201015 yr Author I'm a little confused. When the disk is viewed through mc on a mount like below, it appears as if it has all the data (I believe). At least it shows 401M/931G in the bottom of MC, and I can LS a lot of files, that seems like it could be all(or at least many) of the original files Interestingly, when I look at it as disk1 as it is shared trough unRAID, it contains the top folder structure and a few files that seems like recovered data - 18GB in all. Don't know if that means anything. The ls-output and the directory seen from the disk1 share attached. two-different-views-of-disk1.zip
November 27, 201015 yr Author Having looked at things a bit more, I have a modified Plan B - meet Plan C: It appears that my data from disk1 is available (as per mc screenshot attached here and ls output from earlier). However, still it's a different story entirely when the drive is mounted through unRAID, where only some lost&found is displayed. I'm thinking: I stop the array. I manually mount disk1 and add my 2TB disk in stead of the disk6, that never got the right data anyway after it converted from the parity. Then I could do a simple file system copy of the files disk-to-disk. I still really would like to be able to take some of the files out from the disks and see if they are actually any good. How can I accomplish that? Can I mount a standard external USB disk? Map it from a Win-machine. Map a win-drive from Linux/unRAID console? Anyway, Plan C has the following masterplan, that would be unprotected (i.e. without any parity) until completed: - I put my other precleared 2TB disk in, replacing the 1TB disk6 that was never properly populated - I mount the problematic disk1 and the new 2TB disk - Question: Does the 2TB disk actually have a file system that can be used after being precleared, or does it need to be assigned through unRAID first? - I copy all the files from disk1 to the new 2TB disk - Question: What is the best way to copy the files - simply by a cp -r command or is there a better way? - I remove the disk1, insert the old and (hopefully) still intact disk6 in its place - I mount the old disk6 and the new 2TB disk and copy the files like above - I remove the old disk6 - Potentially migrate at least one of the 400GB disks like above (the old PATA disk for example) - Assign the disks in a proper order in unRAID web interface - Go over the disk share configuration to check for consistency - Start the array and build new parity - this will be like a new unRAID server with prepopulated data. I will of course preserve the retired drives until I have absolute confirmation that my data are intact in their new location. Key question: Will this preserve my data, and is it at all possible to use a model like this?
November 27, 201015 yr Trying to understand the sequence of events here. 1. You started out with disk6 being Disabled, but you were able to access data on all disks with no problem (disk6 data being provided by on-the-fly parity reconstruct) - correct? 2. You want to replace disk6 but your new disk is bigger than Parity, so you power down, move Parity disk to disk6 slot, then put new disk in Parity slot - correct? 3. Server reboots and recognizes the 'swap disable' state - you click Start and server proceeds to copy the data from disk6 (the old parity) to new Parity disk, and this completes without error - correct? 4. But then, when server starts 'reconstruct' phase (to rebuild actual disk6 data), you start getting massive failures on disk1 - correct? If all the above is exactly correct, tell me what you did next. If something above is not correct, tell me how.
November 27, 201015 yr Author Welcome to my chaos Tom Really hope you have some insights into how to get back on track. Original objective: 2 new 2TB drives to be added to a system where all 8 SATA ports and 1 PATA port is already in use. Plan: Remove 1 400GB SATA drive (disk6), add 1 precleared 2TB drive, let swap-disable do it's migration Complication: Came home to a machine, where disk1 somehow during the process dropped out. A LOT of parity corrrctions indicated Situation: - The disk6 data was NOT regenerated correctly on the new disk6(original Parity drive). Drive6 original still exists untouched since disconnection - Disk1 was somehow corrupted, but there appears to be hope for recovery (as per the latest posts) So responding to your questions: 1. You started out with disk6 being Disabled, but you were able to access data on all disks with no problem (disk6 data being provided by on-the-fly parity reconstruct) - correct? No, I started with adding 2TB disk in stead of disk6 (in the physical domain). Disk6 was intact. Objective was a space expansion. 2. You want to replace disk6 but your new disk is bigger than Parity, so you power down, move Parity disk to disk6 slot, then put new disk in Parity slot - correct? Yes, but I simply plug the 2TB disk in the old disk6 physical cable, and then reconfigured drives in the web interface, assigning the 2TB to parity and the 1TB old parity to disk6. 3. Server reboots and recognizes the 'swap disable' state - you click Start and server proceeds to copy the data from disk6 (the old parity) to new Parity disk, and this completes without error - correct? Completes the parity copy without errors aparently. I left it at approx. 88% for work, came home to... 4. But then, when server starts 'reconstruct' phase (to rebuild actual disk6 data), you start getting massive failures on disk1 - correct? ...a situation where massive failures had happened. The top of the status page showed: Parity updated 238435159 times to address sync errors and disk1 appearing as unformatted. Have since run reiserfsck on disk1 including a couple of rebuilds. Now disk1 shared by unRAID looks different from what I see when mounting the disk when unRAID is stopped. Any insights appreciated. I am quite prepared to restore/reconstruct unprotected just to get data back and back on track... Note: I do have additional hardware that can be used in a recovery or migration phase.
November 28, 201015 yr Oh boy... First, you can't simply reassign drives via the Devices page to upgrade, etc. This page is intended to identify FIXED "slot" locations. What I suggest you do is put everything back exactly the way it was before you started on this little adventure. That is, restore your Device assignments the way they were, and cable up all your hard drives the way they were. Assuming the above, if I understand what's happening is your disk1 for some reason has failed, independently and coincidentally to your upgrade attempt, is that correct? Have since run reiserfsck on disk1 including a couple of rebuilds. Now disk1 shared by unRAID looks different from what I see when mounting the disk when unRAID is stopped. I don't see how this is possible. If array is started and you look at the files on disk1 via MC or console, the mount point is /mnt/disk1 If you Stop the array and manually mount the disk, are saying it's contents are different?
November 28, 201015 yr Author "Oh boy..." is not a promising start ... First, you can't simply reassign drives via the Devices page to upgrade, etc. This page is intended to identify FIXED "slot" locations. I thought I was following the procedure for swap-disable. To be very precise, what I actually did is also documented here http://lime-technology.com/forum/index.php?topic=8569.msg86984#msg86984 That appears to be consistent with Joe L.'s instructions, apart from the thread where you describe a crucial extra step: http://lime-technology.com/forum/index.php?topic=9068.msg86754#msg86754 That fixed the issue where I did not get a swap-disable going. So all was looking well and good at that time. And several hour later. Assuming the above, if I understand what's happening is your disk1 for some reason has failed, independently and coincidentally to your upgrade attempt, is that correct? Yep - it appears so. I'm VERY certain that the disk looked normal in the web-interface before and during the rebuild (until 8x% where I left the server to go to work). If you Stop the array and manually mount the disk, are saying it's contents are different? Yes - that is what has me really puzzled as well. If you look at the attached screendump from mc in the recent post (or the ls-output before that) it sees all(or at least many) of my old files. This is with unRAID stopped. If I access Disk1 throught it's unRAID share (unRAID started), I get a different output. See attachments to this post. The impossible - possible... What I suggest you do is put everything back exactly the way it was before you started on this little adventure. That is, restore your Device assignments the way they were, and cable up all your hard drives the way they were. I will reinstate the original configuration, meaning: - Disconnect the 2TB drive and use it's cable to reconnect disk6(old). - Reassign drives in the web interface - Disk6(new) reassigned back as Parity - Disk6(old) reassigned from unassigned to disk6 Disk1 is assumed to be ill still. I do (with my limited insight) however not see how this can bring things closer to a resolve. There is no parity, and the issues with disk1 is not addressed. In fact, I would think that the array would not start at all, as too much is at fault. But if you can confirm that this is the right direction, I will proceed. Thank you again for looking into this. disk1-shared1.txt
November 28, 201015 yr I'm mainly wanting to get back to a known-working configuration & once we get to that & we get the disk1 issues resolved one way or another, then we can address the operation of upgrading the disks. So let's talk a bit about the Devices page first. If you look at one of the servers on the LimeTech website, e.g., the MD-1510, you will see that each disk is plugged into a "slot". That "slot" is connected to a specific disk controller port, ie, either on the motherboard or an add-on card. We need to label the "slots" as follows: Parity, disk1, disk2, ..., diskN. This is so in error reports, etc, when it says, e.g., "disk2" we can point to a specific slot (or disk plugged into that slot) that the information applies to. In the case where you might not be using drive carriers, you still want to come up with some identification scheme, perhaps from top-to-bottom looking at your case where you install the hard drives, where you can identify which is "parity", which is "disk1", etc. The Devices page is defining which physical disk controller port corresponds to the labels "parity", "disk1", "disk2", etc. So once you settle on the physical arrangement, this should not change - make sense? Let's talk about disk1 now. If the array is Stopped it is not possible to view the contents of disk1 because part of the "Stopping" process is to un-mount all the disks. So I'm not sure how you are able to see files on disk1 with the array stopped: - are you manually mounting the disk on some mount point? - what is your boot device (a USB flash I presume)? If I were in your shoes, I would: 1. Temporarily disable any add-ons (such as unmenu, etc) you might have. (why? because it will confuse the communication between you and me.) 2. Cable everything up in a logical manner, make sure the Devices page reflects that. 3. Remove the parity drive by simply removing it's power connector (to simplify things). 4. Now, boot server and observe that array probably won't start because of the changes on Devices page (if it does Start, then Stop it). 5. Now go to webGui devices page and look at all the entries there. You will see an "identifier" inside parenthesis, e.g., "(sdb)" and "(sbc)". 6. For each data disk in the Devices page list, you are going to run reiserfsck from a telnet session as follows: reiserfsck /dev/sdb1 (What you did was use the identifier, prefix with "/dev/" and "1" suffix.) Answer 'Yes' to the prompt. If any disk reports errors, the output of 'reiserfsck' will tell you what to do next; usually it's to re-run with the '-rebuild-tree' option. Do this for every data disk. Whatever you get for the hard drive assigned to disk1 is what you get - if reiserfsck can't recover a file, then sorry to say, it's gone. 7. Now power down, connect parity, and power up. When array comes up, again, it probably won't start. So from telnet you have to type: initconfig (answer Yes to prompt) Now go back to webGui & click Refesh. You should see all drives with "blue dots" next to them. Now Start array and parity sync should start up. After you get this far, then we can talk about uprading your disks to larger ones.
November 28, 201015 yr Author Thank you for the input. In the case where you might not be using drive carriers, you still want to come up with some identification scheme, perhaps from top-to-bottom looking at your case where you install the hard drives, where you can identify which is "parity", which is "disk1", etc. The Devices page is defining which physical disk controller port corresponds to the labels "parity", "disk1", "disk2", etc. So once you settle on the physical arrangement, this should not change - make sense? OK - I got the meaning of the devices page thoroughly screwed up. I thought that it was a logical scheme that had no real meaning in the physical world. And from that logic I came up with the plan B/C. I have however already made a pretty thorough labelling scheme. As can be seen from attachments, I have - physically labeled the disks with the first part of their identifier and the last part of their serial number as it is seen on the devices page - physically labeled the cables 1-4 and R1-R4 matching the SATA/RAID ports (not all the numbers visible on photo) It was merely to keep track of what was where, but I guess it makes a lot of sense in this respect as well. So you suggest to re-organise the devices in the devices page to map to the actual physical ports (where now, I would have SATA4 connected to disk8 and RAID3 connected to disk6) So, for example: Physical SATA1 --> Disk1 Physical SATA4 --> Disk4 Physical RAID2 --> Disk6 Physical PATA1 --> Disk9 Let's talk about disk1 now. If the array is Stopped it is not possible to view the contents of disk1 because part of the "Stopping" process is to un-mount all the disks. So I'm not sure how you are able to see files on disk1 with the array stopped: - are you manually mounting the disk on some mount point? - what is your boot device (a USB flash I presume)? (...) Whatever you get for the hard drive assigned to disk1 is what you get - if reiserfsck can't recover a file, then sorry to say, it's gone. I'm booting from the unRAID USB flash in any case. I did both look at the disk when the array was stopped (mounted manually) and started - with different results. If you look at the mc attachment in my post above here: http://lime-technology.com/forum/index.php?topic=9135.msg87820#msg87820 it displays what can be seen when the array is stopped. My post http://lime-technology.com/forum/index.php?topic=9135.msg87847#msg87847 has the look at disk1 as it is shared when unRAID is started. There is also a post here: http://lime-technology.com/forum/index.php?topic=9135.msg87847#msg87847 where output from "ls" in a console is reported in array started and stopped mode; yielding different results also. When unRAID is stopped, the disk reports my contents. Therefore, I'm concerned about getting the data out as they are seen when unRAID is stopped, as I would expect unRAID when started to not see the data on the disk. The disk1 has had three reiserfsck runs already as can be seen earlier in the thread. The last one with reiserfsck --rebuild-tree -S /dev/sdc1 previous one wihout the -S. That has brought the disk into the current state. If I were in your shoes, I would: 1. Temporarily disable any add-ons (such as unmenu, etc) you might have. (why? because it will confuse the communication between you and me.) 2. Cable everything up in a logical manner, make sure the Devices page reflects that. 3. Remove the parity drive by simply removing it's power connector (to simplify things). 4. Now, boot server and observe that array probably won't start because of the changes on Devices page (if it does Start, then Stop it). 5. Now go to webGui devices page and look at all the entries there. You will see an "identifier" inside parenthesis, e.g., "(sdb)" and "(sbc)". 6. For each data disk in the Devices page list, you are going to run reiserfsck from a telnet session as follows: reiserfsck /dev/sdb1 (What you did was use the identifier, prefix with "/dev/" and "1" suffix.) Answer 'Yes' to the prompt. If any disk reports errors, the output of 'reiserfsck' will tell you what to do next; usually it's to re-run with the '-rebuild-tree' option. Do this for every data disk. Whatever you get for the hard drive assigned to disk1 is what you get - if reiserfsck can't recover a file, then sorry to say, it's gone. 7. Now power down, connect parity, and power up. When array comes up, again, it probably won't start. So from telnet you have to type: initconfig (answer Yes to prompt) Now go back to webGui & click Refesh. You should see all drives with "blue dots" next to them. Now Start array and parity sync should start up. After you get this far, then we can talk about uprading your disks to larger ones. So in this case, it would actually respect all the data found on all the drives in the system? So I would also be able to copy these data out from the server at this point in time? Is there any way of doing so before starting the array, or is the initconfig harmless to any data, as it will simply build parity and nothing else? Would it make sense to have the PARITY drive as one of the 2TB disks already here - in the initconfig situation? - To avoid having to do the swap-disable once again - It would not matter what the parity drive is anyway, as it is being rebuilt from scratch So I could essentially leave the 2TB disk in the disk port for the parity disk (that was the old sde-device's place - I have the original configuration here: http://lime-technology.com/forum/index.php?topic=8569.msg86446#msg86446)
November 28, 201015 yr Author Status update. Things are looking better now. I have performed the reorgansiation as per Toms recommendation "If I were in your shoes, I would...". All but the disk1 completed fast without problems. Disk1-check recommended to do a --rebuild-tree, which I ran for the third time including the attempts earlier in the process/week. This time it actually got to the syntax step, and actually verified a LOT of files, before it suddenly aborted. I would suspect it was very near the end of the job. I was sooooo optimistic, and then it pulled the plug on me So now it is unmountable (manual) again, as there is no superblock... I could at least mount it before. I've started another --rebuild-tree. It will presumably run for several hours now. The just aborted process ran for 9 hours. The console output so far attached (removed a lot of the unimportant stuff to reduce the size). When it hopefully succeeds, I will continue with step 7 and use the 2TB disk as parity. Putty-tower-2010-11-28_150345-reduced.zip
November 29, 201015 yr Status update. Things are looking better now. I have performed the reorgansiation as per Toms recommendation "If I were in your shoes, I would...". All but the disk1 completed fast without problems. Disk1-check recommended to do a --rebuild-tree, which I ran for the third time including the attempts earlier in the process/week. This time it actually got to the syntax step, and actually verified a LOT of files, before it suddenly aborted. I would suspect it was very near the end of the job. I was sooooo optimistic, and then it pulled the plug on me So now it is unmountable (manual) again, as there is no superblock... I could at least mount it before. I've started another --rebuild-tree. It will presumably run for several hours now. The just aborted process ran for 9 hours. The console output so far attached (removed a lot of the unimportant stuff to reduce the size). When it hopefully succeeds, I will continue with step 7 and use the 2TB disk as parity. How much RAM do you have in your server? Joe L.
November 29, 201015 yr Author How much RAM do you have in your server? I have 4GB. 2 paired sets 1GB G.Skill PC3200. I get the following from 'free': root@Tower:~# free total used free shared buffers cached Mem: 3115300 1356728 1758572 0 758420 241616 -/+ buffers/cache: 356692 2758608 Swap: 0 0 0 Regarding the reiserfsck, it is much slower than last time. Now it's running at 5/second, where it ran at 25-30 and sometimes higher the first time.
November 29, 201015 yr Author Unfortunately, the reiserfsck --rebuild-tree failed again. This time it failed due to "Segmentation fault" : Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes Replaying journal: Done. Reiserfs journal '/dev/sdc1' in blocks [18..8211]: 0 transactions replayed ########### reiserfsck --rebuild-tree started at Mon Nov 29 00:17:06 2010 ########### Pass 0: ####### Pass 0 ####### Loading on-disk bitmap .. ok, 244077378 blocks marked used Skipping 15663 blocks (super block, journal, bitmaps) 244061715 blocks will be read 0%.... left 0, 20233 /sec7196 directory entries were hashed with "r5" hash. "r5" hash is selected Flushing..finished Read blocks (but not data blocks) 244061715 Leaves among those 243229 Objectids found 7203 Pass 1 (will try to insert 243229 leaves): ####### Pass 1 ####### Looking for allocable blocks .. finished 0%....20%....40%.Segmentation fault left 131748, 5 /sec root@Tower:~# I could not mount the drive or anything. Bad superblock. I'm now seriously considering removing the drive from the main server. Put in its place the other 2TB drive I have, do the initconfig thing and build the unRAID server from there. Question1: This will still result in the other disks keeping their data, and they would be protected when parity build completes? Question2: I assume all shares has to be re-done in the shares section of the unRAID web-age? The ill-fated disk1 could then be put on a spare machine (my Car-PC re-purposed for a while) boot that machine with my extra unRAID key and the disk1 as the only attached drive, and try to complete the check process there. If it still fails, then apply other hird party tools ro recover the data. I've given it a last chance to complete --rebuild-tree in the server before disconnecting it.
November 29, 201015 yr What version of reiserfsck are you using? Type reiserfsck -V to get the version. You are getting segmentation fault. Basically reiserfsck is crashing before finishing its job. If you are not using version 3.6.21 you can download and install the newer version (that supposedly fixed a similar type of crash) by typing: cd /boot wget http://slackware.cs.utah.edu/pub/slackware/slackware-13.1/slackware/a/reiserfsprogs-3.6.21-i486-1.txz installpkg reiserfsprogs-3.6.21-i486-1.txz Then try the rebuild-tree once more. Joe L.
November 29, 201015 yr Author Thanks for the heads-up. But it is in fact the 3.6.21 that accompanies unRAID 4.5.6. Regarding the RAM question before, the BIOS reports 3072 of 4096 MB usable. I have not enabled neither S/W remapping nor H/W remapping in BIOS. I'm not sure if that is safe to do ? Edit: I actually found out myself that it's unsafe with this specific board: http://lime-technology.com/forum/index.php?topic=5198.msg48378#msg48378 - not specifically for unRAID but a board bug.
November 29, 201015 yr nia - haven't read through the thread you referenced... but if there's a bug on the motherboard that doesn't permit you to use all the RAM, then you need a different motherboard. If there is any question of marginal hardware, you will always be plagued with nagging problems and errors.
November 29, 201015 yr Author There is IMO no problem with the hardware as long as no remapping is attempted. There is solid reports on that. It is an advanced option in the BIOS, that potentially could alleviate the PCI hole (the large reserved space below 4GB) - essentially an attemp for a trick. When not attempting to use this artificial overruling of the inherent architecture issue in the 32bit board/OS domain, the board is regarded as stable as any other Asus board out there. It is not only this board that is struggling with remapping. It's a general thing to avoid according to many accounts out there. Several users in here apparently use the board in normal configuration with no issues. My system has been running without any issues so far (one year - a few upgrades). Only the swap-replace somehow went wrong as the disk1 apparently lost connection at a baaad time. IAs a last resort, I have since last reiferfsck replaced the SATA cable for that disk, as the old one seemed too loose for comfort. Stay tuned - apparently the last attempt of reiferfsck just now completed...
November 29, 201015 yr Author Things are looking much better now. The recovery survived at reboot. Some files appears lost or damaged. At least there is a bit under 2GB more available than last time I looked at the disk (it had about 400MB free before the incident, and also at the last semi-successful reiserfsck). That is absolutely workable. No critical files has got tagged like: file [9130 926] has the wrong block count in the StatData (2443288) - corrected to (2443280) only some recorded TV Shows. So now I will indeed go into your suggested step 7. I assume there is a missing pre-step that is assigning the 2TB disk as parity. Wish me luck...
November 30, 201015 yr Author And now, parity is rebuilding Thank you Tom & Joe for your patient support. Where is the "Donate Case of Beer"-button? This is how things look now: Model / Serial No. Temperature Size Free Reads Writes Errors parity WDC_WD20EARS-00M_WD-WCAZA1026118 38°C 1,953,514,552 - 27 31,431 0 disk1 WDC_WD10EADS-00P_WD-WCAVU0248604 32°C 976,762,552 2,333,696 83,344 27 0 disk2 WDC_WD10EADS-00M_WD-WMAV50602294 29°C 976,762,552 1,336,008 30,663 5 0 disk3 WDC_WD10EADS-00M_WD-WMAV50287415 29°C 976,762,552 466,956 30,755 5 0 disk4 SAMSUNG_HD403LJ_S0NFJ1KLC05846 30°C 390,711,352 944,264 30,746 5 0 disk5 Not installed disk6 WDC_WD10EVDS-63U_WD-WCAV58157919 35°C 976,762,552 145,156 30,827 6 0 disk7 SAMSUNG_HD401LJ_S0HVJ1CLB04953 31°C 390,711,352 953,056 42,171 6 0 disk8 SAMSUNG_HD401LJ_S0HVJ13P110541 30°C 390,711,352 24,292 31,409 6 0 disk9 HDS724040KLAT80_KRFA06RAGV3A2C 47°C 390,711,352 688,484 28,785 5 0 Command area Started Stop will take the array off-line. Parity-Sync in progress. Cancel will stop Parity-Sync. WARNING: canceling Parity-Sync will leave the array unprotected! Total size: 1,953,514,552 KB Current position: 10,762,468 (0.5%) Estimated speed: 21,471 KB/sec Estimated finish: 1507.8 minutes When it has finished, and Parity has been verified, next steps is replacing 2 of the SATA 400GB drives with the other 2TB drive and the currently unused old 1TB parity drive. Then migrate the PATA 400GB to one of the other disks and remove it from the array. Then onwards building a backup unRAID server from the old 400GB disks to be placed in the other end of the house. That however is a completely different story...
December 1, 201015 yr Author The parity was successfully built. It has been verified. All is well , even though I still don't quite know how the few affected files that got their length adjusted by the rebuild process are damaged, but in the overall picture, it really doesn'n matter much given the specific files affected. Next steps was to replace/upgrade two 400GB SATA drives, and remove the 400GB ATA drive (I consider applying it for cache drive putposes to see if it makes any difference - I do not think so). Steps completed so far: One 400 GB replaced with 1TB drive (the old parity drive) + Parity verification. OK. ATA data copied to the 1TB drive from the terminal using the cp-commands as specified in the WIKI "Transferring files within the server..." Now the second 400GB disk has been replaced with the other 2TB drive, which is currently rebuilding. After verifying parity and testing a few files, I will remove the ATA drive as described here http://lime-technology.com/forum/index.php?topic=8562.msg82942#msg82942 The spare disks will probably be used for a backup unRAID server. Thank you again for all your support in this process.
Archived
This topic is now archived and is closed to further replies.