September 5, 201312 yr So, quick question for the guru's. I have replaced a couple of drives in my system recently, not from disk problems, but to add larger drives to my parity and array. So, I have the replaced drives left over. Do these need to be pre-cleared again, or is there a shortcut procedure to get them back into the array for more storage. I think the answer is that the parity needs to be pre-cleared, but I'm not sure about old data disks. I have never had problems with these drives, so I would prefer not to stress them unnecessarily with another pre-clear. If it needs to be done then I will. Thanks.
September 5, 201312 yr why did you replaced them to begin with. all you needed to do was replace the parity drive with the bigger one and than format the old parity after the new one was rebuilt and add it to array along with all the new drives. I think you can just format the drives and add them to array as is no pre-clear needed, but this would trigger the parity rebuild again check out the pre-clear options as I believe you can run a no-correct single pass mode to just zero out the drive fast and less stressful.
September 5, 201312 yr They do have to be cleared to add them to a parity-protected array. You can run the pre-clear script with the "-n" option and it will just do the clear ... skipping the pre and post reads [This takes less than 1/4th as long as a full pre-clear.] ... or you can simply add the drives to the array and UnRAID will clear them -- but the array isn't available during the clear operation in this case. ... the last alternative is to "run at risk" while you add them => do a New Config and add all of the data disks AND the disks you want to add; then assign the parity drive; and then Start the array. It will then do a parity sync => but the array will NOT be parity protected until that sync is done [You can, however, use the array during the sync]. This is the quickest approach ... but also the riskiest, as if you were to have a disk failure during the process you would not be able to rebuild it.
September 5, 201312 yr Yes, you have 0 them if you want to add them the quick way. Quick way means, add to array, format, ready to go. This is because adding 0ed drives to the array doesn't influence parity. (read wiki about parity in unRAID) Therefore, if you do this: ... the last alternative is to "run at risk" while you add them => do a New Config and add all of the data disks AND the disks you want to add; then assign the parity drive; and then Start the array. It will then do a parity sync => but the array will NOT be parity protected until that sync is done [You can, however, use the array during the sync]. This is the quickest approach ... but also the riskiest, as if you were to have a disk failure during the process you would not be able to rebuild it. Without prelceared drives, it means the old data will still be on the drives. That means you will add the old data to your array also. I don't know what happens if you add an old parity drive? In any case, the new parity will be calculated over all drives.
September 5, 201312 yr I don't know what happens if you add an old parity drive? It will simply be formatted -- doesn't need to be cleared as long as it's being added to an array without parity.
September 5, 201312 yr I don't know what happens if you add an old parity drive? It will simply be formatted -- doesn't need to be cleared as long as it's being added to an array without parity. If you say so...then explain how. unRAID recognizes it based on the missing file system or what? But the format won't 0 the drive or? Or will this kind of format take longer?
September 5, 201312 yr I don't know what happens if you add an old parity drive? It will simply be formatted -- doesn't need to be cleared as long as it's being added to an array without parity. If you say so...then explain how. unRAID recognizes it based on the missing file system or what? But the format won't 0 the drive or? Or will this kind of format take longer? Not sure what you question is. If you add ANY drive to an UnRAID array, there are two things that will occur: (1) If the array is parity protected, the new drive will be cleared, so it can be added without impacting the parity protection. But if the array isn't parity protected, this step isn't necessary. [Nor is it needed if the drive has been pre-cleared] (2) If the drive doesn't have a ReiserFS file system, it will be formatted with ReiserFS ... this is a fairly fast process (a few minutes). A format does NOT zero a drive -- that's an entirely different (and MUCH longer) process. Note that if #1 occurs, then the drive will always be formatted, since zeroing the drive will remove any previous file system. But if #1 isn't needed (i.e. the array isn't currently parity protected -- which will be the case with a New Config), then if the drive already has a ReiserFS file system it's simply added (so any data on the disk is preserved); and if it doesn't have a ReiserFS file system (e.g. an old parity drive) it will formatted with one.
September 5, 201312 yr Author Thanks for all the info. One of the reasons I replaced the drive, and rebuilt, was to try to get rid of some of the drives with small (375GB) platters. I was hoping that doing so would speed up my parity check times. Doing so hasn't really changed the parity speed, so I thought I'd just expand the array with the leftover drives.
September 5, 201312 yr One of the reasons I replaced the drive, and rebuilt, was to try to get rid of some of the drives with small (375GB) platters. I was hoping that doing so would speed up my parity check times. Doing so hasn't really changed the parity speed, so I thought I'd just expand the array with the leftover drives. Using drives with higher areal density should have helped your parity check times, unless you still have a lot of disparate drive sizes OR if you have ANY drives left with low areal density. The parity check time can never be faster at any given point in the check than the SLOWEST drive in the array. If you list all of your drives, I can perhaps suggest what changes might help. ... on the other hand, unless you have other performance issues, how long a parity check takes is mostly an academic exercise anyway => in general this is something you only do once/month or so, and most folks do it during hours when it doesn't really matter how long it takes. So you may just want to use all your drives to maximize the array size anyway.
September 5, 201312 yr Author Gary, I'm still in the process of getting rid of the last of the slowest drives, so I'll wait to make a final assessment. I'm using the "tunables" script to get an idea of speed without running a full parity check. I agree that, for the most part, the parity check is an overnight thing that doesn't really affect usage of the array. However, anything that I can do to increase the efficiency is a good thing. When I'm done fully re-tweaking the array structure I will definitely hit you up for some help in getting better speed. Also, I want to say that your posts (along with Joe L and many others) have been a fantastic help in teaching me more about my system. Thanks to all of you who take the time to post thoughtful, well written, educational posts in this forum.
September 5, 201312 yr Not sure what you question is. Sorry. The initial situation was an array (lets say with parity) and ratmice wanted to add his old drives out of the old array. You proposed to do a new config. And I said, that doing so, will include the data of his old drives into the new array since they were not cleared. Basically what you say: then if the drive already has a ReiserFS file system it's simply added (so any data on the disk is preserved) My uncertainty was concerning the old parity drive. You said: It will simply be formatted -- doesn't need to be cleared as long as it's being added to an array without parity. And I wanted to know how unRAID knows that that drive is no data drive. I supposed due to the missing file system. Your answer: If the drive doesn't have a ReiserFS file system, it will be formatted with ReiserFS ... this is a fairly fast process (a few minutes). All OK so far. But that leaves me with a little problem of understanding. Probably because I don't know the ReiserFS in detail. If formatting is not 0ing the drive how can the new parity be correct? In NTFS for example, the drive may have old information in its sectors/blocks but if the MFT has marked them empty the space is allocated free. If you read the drive with a rescue tool you still can retrieve the data. If this is the same with ReiserFS and parity is calcualted block by block, then something is wrong because the drive is actually not empty.
September 5, 201312 yr If formatting is not 0ing the drive how can the new parity be correct? It can't. That's why that only works with a New Config -- which is what I said and what you quoted ["... the last alternative is to "run at risk" while you add them ..."] With a new config, the parity is calculated based on the current set of drives in the config, regardless of their contents. So the array is NOT parity protected when you re-init the config (that's why you're "running at risk"). You only need to zero a drive to add it when your array already has a valid parity drive -- NOT before parity has been initialized. I'll repeat what I said below -- and note the first comment in #1 ... "IF the array IS PARITY PROTECTED, the new drive WILL BE CLEARED ..." ------------------------------------------------------------------------------------------------------- If you add ANY drive to an UnRAID array, there are two things that will occur: (1) If the array is parity protected, the new drive will be cleared, so it can be added without impacting the parity protection. But if the array isn't parity protected, this step isn't necessary. [Nor is it needed if the drive has been pre-cleared] (2) If the drive doesn't have a ReiserFS file system, it will be formatted with ReiserFS ... this is a fairly fast process (a few minutes). A format does NOT zero a drive -- that's an entirely different (and MUCH longer) process.
Archived
This topic is now archived and is closed to further replies.