I'm new to unRAID but have successfully (with help from this forum  ) set up my 1st server. It comprises a fixed 500Gb drive for parity and 2x500gb hdd's mounted in removable caddies.

 

I have several gigs of data on a pc not connected to my lan, i would like to remove one of the data drives & connected it to this non lan'd machine. What is the correct procedure for this?

 

I assume the first thing is to STOP the ARRAY from the main screen of the web gui.

 

Once stopped, do i need to power down or just pull the caddy (they are designated as hot-swappable under Windows)

 

Once I've added the new data, and plugged the caddy back into the server, how do I restart it? Do I just START the ARRAY from the gui & that's it, or do I need to do something to get the parity drive updated, or is it automatic?

 

Thank for any help

 

Nez

I'm new to unRAID but have successfully (with help from this forum  ) set up my 1st server. It comprises a fixed 500Gb drive for parity and 2x500gb hdd's mounted in removable caddies.

 

I have several gigs of data on a pc not connected to my lan, i would like to remove one of the data drives & connected it to this non lan'd machine. What is the correct procedure for this?

 

I assume the first thing is to STOP the ARRAY from the main screen of the web gui.

 

Once stopped, do i need to power down or just pull the caddy (they are designated as hot-swappable under Windows)

 

Once I've added the new data, and plugged the caddy back into the server, how do I restart it? Do I just START the ARRAY from the gui & that's it, or do I need to do something to get the parity drive updated, or is it automatic?

 

Thank for any help

 

Nez

Unless the remote machine can write to a reiserfs file-system you will not be able to do this

(As far as I know, it must be a Linux OS, because I'm not aware of any driver in windows or on a MAC that can "write" to reiserfs.  There is a read-only driver for windows, but none that can write to "reiserfs")

 

Assuming that you can "write" on the remote PC.  (You might be able to boot it on a "live" linux disk... then mount the unRAID disk and the target PC's disk and copy the data under linux)

 

1. Stop the array.

 

2. power down the array.

 

3. move the disk to the other machine.   (if you were to power up now, your array would show the disk as missing.  You have NO parity protection against a second disk failing)   Much easier alternative.... add a temp lan connection.

 

4. Write to the disk on the remote PC.

   At this point, you do NOT have parity protection for ANY of your disks.   If any fail, their data will be lost.

 

5. move the disk back to the unRAID server.

 

6. power up the unRAID server.  (It should start itself)

 

7. Press the Parity "Check" button.  It will find many-many-many parity errors (and it will correct them as it finds them) 

Unraid has no way to know you changed the  data behind its back... (while the disk was in the other machine) so it will not have good parity even though it thinks it does. 

 

8. Only after the parity check is complete will you have parity protection for your data once more. (including the new data you wrote on the other PC)

 

I would power down when changing drives... even though the drive might be able to handle the plug/un-plug... I don't think unRAID can handle it logically.

 

There is one exception to this... If the drive you use to transfer data is a USB drive, and not part of the array, you can safely plug and un-plug it.  It will NOT be part of your protected array, but you will be able to mount and copy from its contents to the protected array.   Parity is automatically maintained during this process, so you will have parity protection during the entire process.  The unMENU add-on package makes this process of mounting the usb drive easy.  If you use an NTFS file system, it will make the transfer pretty easy.   See the wiki for details. http://lime-technology.com/wiki/index.php/Mounting_an_external_USB_drive_having_an_existing_NTFS_file_system_in_READ/WRITE_mode_to_transport_files_from/to_unRaid_server

 

Joe L.

Thanks Joe for your very clear and detailed response!

 

A temp LAN is not an option as the machine is at another location, but knowing that the file system is not writable under Windows sort of forces the issue a bit (I obviously wrongly assumed it was NTFS, as that is how it is reported under Windows).

 

I have an Ubuntu live CD I could use at the other location, but I will probably try an external HDD & go that route.

 

Thanks again for your invaluable help.........this has to be the most helpful forum I've used in years!

 

Nez 

Thanks Joe for your very clear and detailed response!

 

A temp LAN is not an option as the machine is at another location, but knowing that the file system is not writable under Windows sort of forces the issue a bit (I obviously wrongly assumed it was NTFS, as that is how it is reported under Windows).

 

I have an Ubuntu live CD I could use at the other location, but I will probably try an external HDD & go that route.

 

Thanks again for your invaluable help.........this has to be the most helpful forum I've used in years!

 

Nez 

 

It is much easier to bring an external disk to the unRAID server, than to take a disk out of the unRAID server and take it to an external machine.

Yes, it does sound easier, so I'll try that. I have a drive I can use that's NTFS formatted already. I'll also check out the wiki link Joe posted

 

thanks again guys

 

Nez

5. move the disk back to the unRAID server.

 

6. power up the unRAID server.  (It should start itself)

 

7. Press the Parity "Check" button.  It will find many-many-many parity errors (and it will correct them as it finds them) 

Unraid has no way to know you changed the  data behind its back... (while the disk was in the other machine) so it will not have good parity even though it thinks it does. 

 

8. Only after the parity check is complete will you have parity protection for your data once more. (including the new data you wrote on the other PC)

 

I can't help thinking that this may not be an optimal process, because I believe it exposes your good data to potential corruption.  Let me explain...

 

After you insert the modified drive and start the array, unRAID thinks it has valid parity for all of your data, and by running a parity check, you correct its misconception and force it to rebuild the parity from the ground up.  So far, so good.

 

But what happens in the meantime, if it encounters a data error on one of your untouched drives at a point on the disk which has not yet had its parity rebuilt?  unRAID still thinks its parity for that bit is valid, and will "correct" the error without you being aware of it.  But since the corresponding bit on the temporarily-removed drive may have been flipped by the external write, there's a 50-50 chance that it will "correct" that bit incorrectly!  And then it will write it back to the drive, making the the (possible) change permanent!

 

Since you have to real protection from the moment you insert that modified drive (because the parity is now totally unreliable), it seems dangerous to let unRAID think you do.

 

Instead, I suggest it would be better to blow away the parity entirely before inserting the modified drive, and build parity again from scratch once it's inserted and the array is started unprotected.  You may feel naked for a while but the "protection" of unreliable parity is a dangerous illusion because in reality you are unprotected until the parity is rebuilt.  IMHO in that situation it would be preferable to be alerted to an error and have the opportunity to correct it by other means, than have unRAID blissfully "correct" - and potentially permanently corrupt - your data without your knowledge.

 

So my suggested process would be:

 

5. Take the modified disk back to the unRAID server but do not insert it yet.

 

6. Blow away unRAID's parity. (remove the parity drive from the array?)

 

7. insert the disk back into the unRAID server.

 

8. power up the unRAID server.  Your drive should be added back into the array, which will be running unprotected

 

9. Add the parity drive back into the array and built parity from scratch.

 

10. Only after the parity build is complete will you have parity protection for your data once more. (including the new data you wrote on the other PC)

 

Unfortunately I haven't used unRAID enough yet to know the best sequence of commands and operations to implement this process, so I'll aver to the experts, if anyone would like to pick up on it.  Perhaps there's a simpler way to tell it that the parity is invalid and needs to be built from scratch?

 

Unfortunately I haven't used unRAID enough yet to know the best sequence of commands and operations to implement this process, so I'll aver to the experts, if anyone would like to pick up on it.  Perhaps there's a simpler way to tell it that the parity is invalid and needs to be built from scratch?

There are... two ways.

1. Stop the array, check the checkbox under the button labeled "restore" and click it.

It does not restore data, but instead it restores your array configuration to where it was before you calculated parity... and uses the currently existing and working drives to start an entirely new parity calc.    You would never use this if any of your drives had failed, since it would throw awa any parity data that would have let you recover their data.

 

2. Yet another method (as an alternative) is to stop the array, go to the devices page, un-assign parity, then go back to the main page, and start the array.

Then, stop the array once more, re-assign parity, go back to the main page and start the array again.  It should then start to populate parity with a new set of calculations.

 

Oh yes, you are correct... the original method initially described in my prior post could, in error, correct a "read" error on a data drive from bad data/parity.  (I was not thinking of that possibility, as "read" errors should not be occurring... but you know... with enough tries, and enough people... one will occur, it is only a matter of time.  It is bad enough you do not have parity protection... it is worse if it leads to a corruption of your data.)

 

Joe L.

It's just not a good idea to lose parity protection. Both of the situations are bad. If you destroy parity and have a data disk fail while rebuilding, you're in a world of hurt.

I can't help thinking that this may not be an optimal process, because I believe it exposes your good data to potential corruption.  Let me explain...

 

After you insert the modified drive and start the array, unRAID thinks it has valid parity for all of your data, and by running a parity check, you correct its misconception and force it to rebuild the parity from the ground up.  So far, so good.

 

But what happens in the meantime, if it encounters a data error on one of your untouched drives at a point on the disk which has not yet had its parity rebuilt?  unRAID still thinks its parity for that bit is valid, and will "correct" the error without you being aware of it.  But since the corresponding bit on the temporarily-removed drive may have been flipped by the external write, there's a 50-50 chance that it will "correct" that bit incorrectly!  And then it will write it back to the drive, making the the (possible) change permanent!

 

I mulled over this, whether to say anything or not, especially since I was not completely confident I understood your reasoning here, as to why this was dangerous.  But I'm pretty sure there is a misconception here, so I'll address that, and stand corrected if necessary as to the rest.  A parity check NEVER changes a data bit, only the parity bit and only if necessary.  The data bits are considered to be correct, the parity bit is corrected if the calc is wrong.  So if there was a data error on another disk, there would be a read error reported, and the whole process will probably stop, because it cannot generate parity for the current block, without access to the block resulting in a read error.  Since this could happen at any time, although very rare, I don't particularly see any additional danger here when running Joe's procedure.  That is, I don't see anything in this particular process that is especially vulnerable, other than the obvious fact that parity is wrong for the extent of the blocks that were modified while removed.  Now, I may not be understanding what you mean by finding a data error.

 

Your alternative method will certainly work, but I'm not sure it is justified, when a simple parity check should work fine.  If there is a read error on another drive, that is going to be a bad situation no matter what, or when.  I suppose this is one more case where a preceding parity check would be a very good idea, to verify the integrity of all sectors of all drives, and all of the parity info.

I mulled over this, whether to say anything or not, especially since I was not completely confident I understood your reasoning here, as to why this was dangerous.   But I'm pretty sure there is a misconception here, so I'll address that, and stand corrected if necessary as to the rest.  A parity check NEVER changes a data bit, only the parity bit and only if necessary.  The data bits are considered to be correct, the parity bit is corrected if the calc is wrong.  So if there was a data error on another disk, there would be a read error reported, and the whole process will probably stop, because it cannot generate parity for the current block, without access to the block resulting in a read error.  Since this could happen at any time, although very rare, I don't particularly see any additional danger here when running Joe's procedure.  That is, I don't see anything in this particular process that is especially vulnerable, other than the obvious fact that parity is wrong for the extent of the blocks that were modified while removed.  Now, I may not be understanding what you mean by finding a data error.

 

Your alternative method will certainly work, but I'm not sure it is justified, when a simple parity check should work fine.  If there is a read error on another drive, that is going to be a bad situation no matter what, or when.  I suppose this is one more case where a preceding parity check would be a very good idea, to verify the integrity of all sectors of all drives, and all of the parity info.

 

Perhaps I didn't explain myself very well; I wasn't suggesting that the parity check would change the data, but that it could get inadvertently changed by a failure in an area that hadn't been checked yet.

 

Let's start by looking at a perfectly healthy array with good parity.  As I understand the way the protection process works, if a read error is detected on, say drive2, then the corresponding bits on the other data drives and the parity drive are read, and the missing bit is calculated and returned to the requestor.  Subsequently, unRAID writes the calculated bit back to the drive that reported the error, which should trigger a track reallocation by the drive firmware if needed.

 

That's all well and good when all the data and parity are in sync.  But by modifying one of the drives outside of unRAID, and not telling it that the parity is now crap, that same process could inadvertently corrupt the data in the event of such an error.

 

Let's take a hypothetical array with two data drives plus parity.  We remove and modify drive1, reinsert it, and start a parity check which starts from sector 0 and works its way up.

 

Now while that parity check is happening and has gotten as far as sector 5000, drive2 (which was never removed from the array) encounters a read failure at sector 10000.  UnRAID dutifully reads sector 10000 from drive1 and sector 10000 from the parity drive, and calculates what must have been in the missing sector on drive2.  That's fine if sector 10000 on drive 1 was not modified by the external process, or was modified but just happened to get written back exactly the same, but if any bits in that sector were flipped by the external write, then the corresponding parity bits are now wrong and the calculated missing bits will also be wrong.

 

But unRAID doesn't know that it's wrong, and goes ahead and presents the data to the requestor as perfectly valid (because that's what the parity protection is supposed to do, after all), and it then writes that sector back to drive2, permanently corrupting that drive without anyone ever knowing.

 

If instead the parity had been discarded and was being built from scratch, then unRAID would report the error to the requestor because it had not yet gotten as far as the failing sector, and the user would have an opportunity to recover what he could.  At the very least would know that his data was irretrievable and could restore from backup, but at least he'd know about it!