psychodad1000

Probably putty connection. Any process you expect to take a long time should be done in a screen session so you can disconnect and resume as needed. Screen can be installed from NerdTools plugin. Google Linux Screen Command. Noob still at it. Bear with me.... Forgot about screen. Used screen to get the files copied to /t on destination. Ran rsync, results were good. 10 - Now is the good time to move the files in the "t" directory to the root on [dest]. I do this with cut and paste from Windows explorer. All I see in explorer are user shares. How do I see the disk contents so I can move /t to the root. I was going to try Midnight Commander but chickened out.

Sorry, I guess I'm going to be the problem child.... Popped in a new 4TB drive and formatted XFS. Everything looked good. Created t folder on new drive. Started Putty, executed command: cp -rpv /mnt/disk1/* /mnt/disk7/t. System started copying 2TB from disk1 to disk7, files names flying by at the speed of light (almost). Came back some hrs later and find this msg: "Network Error:software caused connection abort" . Only 1.2 of the 2TB was copied. I left it overnite to see if it was just the putty connection to my computer that failed and hopefully the copy process was still running. No joy. The copy did stop at 1.2TB. All drives are still green balled. I visually checked and many files were copied to the t folder of the new drive. Ran rsync and got a long list of files which didn't copy. Anyone else have the copy command bomb midway thru the process? What should I do now? Reformat the drive and try again?

Rebuilding an empty filesystem (freshly formatted drive) is no quicker than a full drive. Every bit of the entire disk will be rebuilt regardless. Parity knows nothing of filesytems. In order to change filesystems, you are going to have to copy from an old filesystem disk to a new filesystem disk anyway you do it, so if you have enough slots, I think it would be easier to just preclear the new disks, add them to new slots and format them to the new filesystem, copy from the old filesystem disks to the new filesystem disks, then New Config without the old disks and rebuild parity. Thanks for the reply. I thought it was too good to be true. I guess there really is "no free lunch".

Don't think I saw this scenario: Disk 1 - 2TB (1TB free) Disk 2 - 2TB (1TB free) I want to move the files from Disk 1 to Disk 2 to create an empty drive. Format Disk 1 to XFS. Replace Disk 1 with a new 4TB drive and rebuild. The result will be a larger drive formatted XFS. Correct? I assume the rebuild would go quickly since the drive is empty? My actual scenario involves (5) 2TB drives and a 3TB drive but still results in replacing an emptied 2TB with a 4TB. I know it would be easier to just add the 4TB drive but I would like to start replacing the smaller 2TB drives with 4TB drives. Is there an easier way?

Update... Unraid rebuilt new parity drive, I didn't check it decided to use it since the first of the month was just a couple of days away. It completed the monthy check this am with no errors. I added a new 3TB data drive, after preclear, formatted, and now I'm filling it. Whew, all that anxiety over a corrupted file on the stick. All is well. Thanks for a great product.

chkdsk says: \config\secrets.tdb fist allocation unit is not valid. Ran chkdsk /f. It apparently deleted the file, I couldn't find it or a found folder. Restarted unraid. Reassigned drive. Started array. It started the Parity-Sync, then I got the msg "The connection was reset" again. Although I can now see my shares. So that much is fixed. I guess I'll let the parity finish building and go from there. A quick check of the log file didn't reveal any errors. I'll cross my fingers. Thanks for the reply mr-hexen.

I'm upgrading my parity drive from 2T to 4T. I ran a couple preclears on the drive in a separate machine first. Stopped the array. Unassigned the drive and powered down. Removed existing parity and installed new drive in same slot. Powered up and assigned new drive as parity. Started array and let it rebuild new parity. When finished, ran a check to confirm parity. All green balls. Tried to access files from Windows box and couldn't connect to Tower. Rebooted unraid server. Still could not connect to tower to see files. Checked the drives via gui and it tells me the parity drive is wrong. It still references the old drive?? So I start over again, unassign the new drive and go through all the steps again. The same thing happens. After rebuilding the new parity, and any kind of reboot, it still thinks the old smaller parity drive should be installed and gives me an error. Just had a thought, as soon as it starts to rebuild parity on the new drive, I get a network failure error, I don't remember the exact words. Could it be failing to write the new drive id to the configuration file on the USB?? I had been refreshing the web page and everything looks normal while it starts the rebuilding the parity. Any ideas?? I'm currently rebuilding the parity on the new drive for the third time, but I don't expect the results to be any different. I've attached a log...of interest to me are: Oct 26 11:42:23 Tower kernel: write_file: error 30 opening /boot/config/super.dat Oct 26 11:42:23 Tower kernel: md: could not write superblock from /boot/config/super.dat Oct 26 11:42:26 Tower kernel: write_file: error 30 opening /boot/config/super.dat Oct 26 11:42:26 Tower kernel: md: could not write superblock from /boot/config/super.dat Any help would be appreciated. Oops, version 5.0.5. syslog-2014-10-26.txt

Thanks for the replies.... I'm at a loss. I pulled all the drives out of the cage, hooked them up & Unraid booted. I put all the drives back into the cage and it booted again. I don't have a clue why but it is working now. I reseated all the cables before I started doing any troubleshooting. Anyway, I'm preclearing the new drive now. The only thing different at this point is the 5th (last) controller cable isn't plugged in the cage because I don't need it. I may get brave & plug it in down the road. AFTER SHUTTING EVERYTHING DOWN. Thanks

UnRAID 4.7, upgraded to Plus today so i could add a third data drive. After stopping the array (but not shutting down UnRAID), I shoved the drive into my Norco SS-500 bay. By that time, I started reading the instructions (a nice time to start reading) and they said to shutdown the server to add a drive. I then shutdown UnRAID and rebooted (with new drive installed). Now I can't get UnRAID to boot. Are hot swap bays not hot swap?? I pulled all the drives and was able to boot into linux. Could someone take a look at my log and point me in the right direction?? It apparently isn't seeing the drives?? Hopefully I just messed up UnRAID and not a controller. Many Thanks BTW SuperMicro MB, MBD-X8SIL-F-O syslog-20120820-020416.txt