Timbiotic Posted February 19, 2018 Posted February 19, 2018 Version 6.4.1: I have followed the procedure to upgrade/swap the parity drive. Basically upgrading from 3tb parity and 1tb drive to 4tb parity and moving current parity to other spot. Everything went well until I hit the "copy" spot. It started copying but now is no longer responsive via gui. I can SSH or console and ping it still fine. Should I wait or fat finger it and let it just build parity from scratch? Thankfully i unbalanced all data of the data drive first. Is there a way i can check the progress or even if it is still running via terminal?
Timbiotic Posted February 19, 2018 Author Posted February 19, 2018 It finished just now. But i realized this from another post saying to check the syslog. For future wanders you can check completion there using "cat /var/log/syslog" Feb 18 22:29:37 lillis emhttpd: copy: disk7 to disk0 running Feb 19 00:00:01 lillis Plugin Auto Update: Checking for available plugin updates Feb 19 00:00:03 lillis Plugin Auto Update: Auto Updating community.applications.plg Feb 19 00:00:03 lillis root: plugin: running: anonymous Feb 19 00:00:03 lillis root: plugin: running: anonymous Feb 19 00:00:04 lillis root: plugin: creating: /boot/config/plugins/community.applications/community.applications-2018.02.16.txz - downloading from URL https://raw.github.com/Squidly271/community.applications/master/archive/community.applications-2018.02.16.txz Feb 19 00:00:04 lillis root: plugin: checking: /boot/config/plugins/community.applications/community.applications-2018.02.16.txz - MD5 Feb 19 00:00:04 lillis root: plugin: running: /boot/config/plugins/community.applications/community.applications-2018.02.16.txz Feb 19 00:00:04 lillis root: plugin: running: anonymous Feb 19 00:00:04 lillis Plugin Auto Update: fix.common.problems.plg version 2018.02.18 does not meet age requirements to update Feb 19 00:00:04 lillis Plugin Auto Update: NerdPack.plg version 2018.02.17 does not meet age requirements to update Feb 19 00:00:05 lillis Plugin Auto Update: user.scripts.plg version 2018.02.16 does not meet age requirements to update Feb 19 00:00:05 lillis Plugin Auto Update: Community Applications Plugin Auto Update finished Feb 19 07:42:50 lillis login[4320]: ROOT LOGIN on '/dev/tty1'Feb 19 07:44:41 lillis emhttpd: copy: disk7 to disk0 completed Feb 19 07:46:15 lillis kernel: usb 3-2: USB disconnect, device number 4
trurl Posted February 19, 2018 Posted February 19, 2018 Glad you got it worked out. Just thought I would comment for your future reference, and for others that might read this thread. Perhaps your description is incomplete, but it doesn't seem like there was any reason to use the parity swap procedure. That procedure is intended to be used when you have a disabled data disk and you want to replace the parity with a larger disk and reuse the former parity disk to rebuild the disabled disk. The point being to allow you to buy a larger disk instead of having to buy one the same size as existing parity. I know this sounds similar to what you did, but in the scenario where there isn't a disabled data disk, you can simply replace parity with a larger disk and resync (rebuild) parity, then replace a data disk with the old parity disk and rebuild it. It really sounds as if you went to a lot of extra trouble, including moving all the data off the data disk you replaced.
Timbiotic Posted February 19, 2018 Author Posted February 19, 2018 Maybe we arent connecting. I started with 3tb Parity 1tb Data Disk 4tb New disk. I have an 8 disk array. I dont have room in my case to keep the 1tb disk. So i followed the parity swap procedure to get rid of the 1tb data disk, move the 3tb parity to its spot, and make the 4tb the new parity. I unbalanced first because i am paranoid and didnt want to lose data.
trurl Posted February 19, 2018 Posted February 19, 2018 No point in continuing this thread. For anyone interested, he started a new one here:
trurl Posted February 19, 2018 Posted February 19, 2018 25 minutes ago, Timbiotic said: Maybe we arent connecting. I started with 3tb Parity 1tb Data Disk 4tb New disk. I have an 8 disk array. I dont have room in my case to keep the 1tb disk. So i followed the parity swap procedure to get rid of the 1tb data disk, move the 3tb parity to its spot, and make the 4tb the new parity. I unbalanced first because i am paranoid and didnt want to lose data. Just one more comment on this. Still no reason to do parity swap just because you don't have room for an additional disk. You don't need room an additional disk. You could have just: replace parity and resync, then replace 1TB data and rebuild. No extra slots required.
Timbiotic Posted February 19, 2018 Author Posted February 19, 2018 copy/move seems faster than rebuild. That is why i usually go with unbalance and preferred the swap method. It took me 9 hours to copy the parity, rebuild / resync usually takes longer. Might be different in different setups but that is my experience.
trurl Posted February 19, 2018 Posted February 19, 2018 21 minutes ago, Timbiotic said: copy/move seems faster than rebuild. That is why i usually go with unbalance and preferred the swap method. It took me 9 hours to copy the parity, rebuild / resync usually takes longer. Might be different in different setups but that is my experience. But after the parity copy, the parity swap procedure rebuilds the data disk. So you get a rebuild anyway. Did you think that since the disk was empty it wouldn't have to be rebuilt? An empty disk is not a clear disk.
Timbiotic Posted February 19, 2018 Author Posted February 19, 2018 was hoping the format might clear it, but i also figured rebuilding a blank disk wouldn't take as long. Is that wrong? Does it not matter if its blank or full for rebuild?
itimpi Posted February 19, 2018 Posted February 19, 2018 Just now, Timbiotic said: was hoping the format might clear it, but i also figured rebuilding a blank disk wouldn't take as long. Is that wrong? Does it not matter if its blank or full for rebuild? The time for a rebuild is determined by the size of the disk, and is completely unaffected by its contents.
Timbiotic Posted February 19, 2018 Author Posted February 19, 2018 would a preclear change that? Although a preclear takes a long time too. I think i am getting it now.
trurl Posted February 19, 2018 Posted February 19, 2018 Just now, Timbiotic said: was hoping the format might clear it, but i also figured rebuilding a blank disk wouldn't take as long. Is that wrong? Does it not matter if its blank or full for rebuild? Rebuild writes every bit of the new disk. You say "blank disk" but that phrase doesn't really have a clear meaning. All bits of a disk have some value. A clear disk is all zeros. A clear disk can be added to a new data slot in an array with valid parity and parity will remain valid since the zeros don't affect parity. On the other hand, a formatted disk isn't clear, and so its contents have some affect on parity. As mentioned, "format" means "write an empty filesytem". The empty filesystem is represented by data on the disk. Also, all of the data that is not part of the empty filesystem is still there if the disk wasn't clear just before it was formatted. So all of those bits are part of the parity calculation. Another thing that these details should help you understand, if you want to format a disk that will be part of the array, you must do so while the disk is in the array and the array is started. Any attempt to format a disk otherwise invalidates parity.
trurl Posted February 19, 2018 Posted February 19, 2018 And as you may be aware, deleting files (such as when moving them to other disks) doesn't "clear" the part of the disk they were on. It just marks them as deleted from the directory. This is why "undelete" is sometimes possible if they haven't been overwritten by some other file. So, when you empty a disk by moving all its files, most of the bits on the disk are really still there, and they are all still part of the parity.
Timbiotic Posted February 19, 2018 Author Posted February 19, 2018 Yes i knew about the mark for deletion, i have had to recover files for friends more times than I care to admit. I am just not familiar with how the parity in unRAID works. Thanks for explaining that. So for future If you are doing multiple disks, it seems best to copy data to other disks with parity off (for speed) add the new disks and resync? If just one, just replace the drive and let it rebuild?
trurl Posted February 19, 2018 Posted February 19, 2018 I prefer to do things one at a time, even though I have good backups, but I'm not in a hurry. How are your backups? Parity in unRAID treats everything as a bunch of bits. Here is the wiki on parity: https://lime-technology.com/wiki/UnRAID_6/Overview#Parity-Protected_Array The other thing to understand is that unRAID parity is realtime. Any write to the parity array updates parity at the same time. And anything that is not a read is a write. Writing a file is a write, copying a file is a write, deleting a file is a write (mark for deletion), moving a file is a write (maybe 2 writes if moving to another disk, since it is really a copy followed by a delete, and formatting a disk is a write (write an empty filesystem). Sometimes I can answer an unRAID question about something I haven't done recently or even ever, simply because I understand parity.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.