I started my array with 5 x 2TB greens and 6 x 1TB blacks which is about full. The blacks are now past the 5 year mark age wise, showing no problems but I had one in a desktop that died recently, so decided maybe I should upgrade the array instead of wait for the inevitable. 6x1TB takes up a lot of physical drive space too which I am also out of.

 

Buying new drives vs. buying a new case (ie, a norco) to hold aged 1TB drives seems like a waste with 4-6 TB drives becoming common.

 

So, I bought 4x4TBs, already have another 2x2TBs and a 3TB laying around that could throw into the array if I upgraded the parity drive as well as 2 4in3 enclosures (physically get to add 2 more drives, bonus).

 

So, precleared a new 4TB drive and went through the 1200 minutes it took to re-write parity... replaced one 1TB drive with a 4TB which took about 800 minutes.

 

Had a plan to replace one drive at a time I think its going to take very long and take a lot of reads and writes and a lot of minutes.

 

Notwithstanding the risk of running without parity, would it be faster and less unnecessary read/writes to just disable the parity drive, copy the 6TB over to another system and then just rebuild the parity drive after all the drives are changed and the 6TB of data has been written back to that part of the array?

Okay, your original config had a 2TB parity, 4 2TB data, and 6 1TB data ... for a total of 14TB of space.

 

Your four 4TB drives alone will provide 12TB of space ... add the 3TB you have to that and you're well past your original space with only 5 drives.

 

What you COULD have done was to simply remove ALL of your drives;  create a new configuration with the 4TB drives and a 3TB drive;  then copy the old drives to the new array across your network one-at-a-time, either without a parity drive assigned (faster, but not fault-tolerant), or with a parity drive (so it's fault tolerant).

 

But since you've already started making some changes, you can do it a bit differently.  I'm assuming the following:

 

=>  You've already upgraded to a 4TB parity drive and, if I understand it correctly, have upgraded one of the 1TB drives to a 4TB drive.

 

=>  You're willing to run "at risk" (without fault tolerance) to make things work faster

 

So, what you can do now is a "New Config", and assign all of your CURRENT data drives, but NOT a parity drive.

 

Then copy all of the data from 3 of the remaining 1TB drives to the 4TB drive you've already got in the array (the one you upgraded from 1TB to 4TB, which clearly should have 3TB of available space).

 

Now shut down; remove the 3 1TB drives you just copied the data from (you can confirm you're removing the right drives to carefully noting the serial numbers of the drives in the Web GUI before you shut down).

 

Add your other 2 4TB drives and the 3TB drive to the system (where the 1TB drives were).

 

Now do another New Config; but this time assign the extra 4TB and 3TB drives to the array in addition to your remaining drives.  You can still leave parity unassigned.  The new drives will need to be formatted, but that's a fairly quick operation.

 

Now copy the data from the other 1TB drives to one of the new 4TB drives.

 

Now do yet another New Config ... leaving out the 1TB drives (which you no longer need) ... and this time assign the parity drive.    When you start the array it will do a new parity sync (a long operation, as you know).

 

When that's done, you won't have any 1TB drives remaining; and you'll have a LOT of free space 

 

IMPORTANT NOTE:  When you copy/move the data from one drive to another, do it using DISK references, NOT via the user shares.  e.g. if you have a share called "Movies" and are moving data from disk3 to disk2, move it from \\Tower\disk3\Movies  to  \\Tower\disk2\Movies.    DO NOT reference it using the user share [i.e. \\Tower\Movies ].    There's a MAJOR issue if you try to move data using the user share reference that will result in a complete loss of data !!

 

IMPORTANT NOTE:  When you copy/move the data from one drive to another, do it using DISK references, NOT via the user shares.  e.g. if you have a share called "Movies" and are moving data from disk3 to disk2, move it from \\Tower\disk3\Movies  to  \\Tower\disk2\Movies.    DO NOT reference it using the user share [i.e. \\Tower\Movies ].    There's a MAJOR issue if you try to move data using the user share reference that will result in a complete loss of data !!

 

Hey Gary, can you expand on this? Usually I just copy across the network (windows SMB) using explorer from one disk to another disk. Does this ISSUE happen doing it this way? I don't usually type any paths in, but nail down through the folders to specific disks.

IMPORTANT NOTE:  When you copy/move the data from one drive to another, do it using DISK references, NOT via the user shares.  e.g. if you have a share called "Movies" and are moving data from disk3 to disk2, move it from \\Tower\disk3\Movies  to  \\Tower\disk2\Movies.    DO NOT reference it using the user share [i.e. \\Tower\Movies ].    There's a MAJOR issue if you try to move data using the user share reference that will result in a complete loss of data !!

 

Hey Gary, can you expand on this? Usually I just copy across the network (windows SMB) using explorer from one disk to another disk. Does this ISSUE happen doing it this way? I don't usually type any paths in, but nail down through the folders to specific disks.

Sounds like you are using the disk shares. The problem only affects moving with user shares.

IMPORTANT NOTE:  When you copy/move the data from one drive to another, do it using DISK references, NOT via the user shares.  e.g. if you have a share called "Movies" and are moving data from disk3 to disk2, move it from \\Tower\disk3\Movies  to  \\Tower\disk2\Movies.    DO NOT reference it using the user share [i.e. \\Tower\Movies ].    There's a MAJOR issue if you try to move data using the user share reference that will result in a complete loss of data !!

 

Hey Gary, can you expand on this? Usually I just copy across the network (windows SMB) using explorer from one disk to another disk. Does this ISSUE happen doing it this way? I don't usually type any paths in, but nail down through the folders to specific disks.

 

As trurl noted above, you're fine if you're going to specific disks.    The key is to be sure you're specifying the specific disk -- NOT just the user share.      It's a complex issue ... and not likely to be fixed anytime soon (it's debatable whether it's actually a "bug" or just a side-effect of the way Linux file systems work).    The issue has been discussed a good bit here:  http://lime-technology.com/forum/index.php?topic=34480.0

 

I outlined it in one of my posts like this: 

 

"... The problem, in a nutshell, is that the user is copying a file from what is logically the same "drive" onto itself ... i.e. a copy from \\Tower\disk1\MyDVDs  to  \\Tower\MyDVDs  is effectively the same thing as copying a file from \\Tower\MyDVDs  to itself.    Most OS's will not allow this, or will automatically append a suffix to the filename to differentiate the two files.    But since the two references are different, the "copier" (whether it's a Windows, Mac, or Linux utility) doesn't realize that's what's happening.    ... and the user simply isn't thinking about that. "

 

What happens, due to the way the file system works, is that the file becomes a zero length file ... i.e. all of the data in it is LOST !!

 

The issue is trivial to avoid -- if you want to move a file that's in a user share from one disk to another just do it using the disk share references.  (which I believe is what you're already doing)

 

 

IMPORTANT NOTE:  When you copy/move the data from one drive to another, do it using DISK references, NOT via the user shares.  e.g. if you have a share called "Movies" and are moving data from disk3 to disk2, move it from \\Tower\disk3\Movies  to  \\Tower\disk2\Movies.    DO NOT reference it using the user share [i.e. \\Tower\Movies ].    There's a MAJOR issue if you try to move data using the user share reference that will result in a complete loss of data !!

 

Hey Gary, can you expand on this? Usually I just copy across the network (windows SMB) using explorer from one disk to another disk. Does this ISSUE happen doing it this way? I don't usually type any paths in, but nail down through the folders to specific disks.

 

As trurl noted above, you're fine if you're going to specific disks.    The key is to be sure you're specifying the specific disk -- NOT just the user share.      It's a complex issue ... and not likely to be fixed anytime soon (it's debatable whether it's actually a "bug" or just a side-effect of the way Linux file systems work).    The issue has been discussed a good bit here:  http://lime-technology.com/forum/index.php?topic=34480.0

 

I outlined it in one of my posts like this: 

 

"... The problem, in a nutshell, is that the user is copying a file from what is logically the same "drive" onto itself ... i.e. a copy from \\Tower\disk1\MyDVDs  to  \\Tower\MyDVDs  is effectively the same thing as copying a file from \\Tower\MyDVDs  to itself.    Most OS's will not allow this, or will automatically append a suffix to the filename to differentiate the two files.    But since the two references are different, the "copier" (whether it's a Windows, Mac, or Linux utility) doesn't realize that's what's happening.    ... and the user simply isn't thinking about that. "

 

What happens, due to the way the file system works, is that the file becomes a zero length file ... i.e. all of the data in it is LOST !!

 

The issue is trivial to avoid -- if you want to move a file that's in a user share from one disk to another just do it using the disk share references.  (which I believe is what you're already doing)

 

Thx. Wow...always amazed at what you guys know. That's the trouble with coming to puters late in life - too much to learn and not enough time to do so with other responsibilities. Always appreciated.