1)  Dual parity support?  I believe the first time I came across unRAID this feature was being considered.  Whatever happened to it?

2)  Is LACP and VLAN trunking/tagging supported?  From what I can gather on the forum LACP is and turnking is not but I haven't seen any recent webGUI pics or an official detailed feature list.

3)  According to here http://lime-technology.com/wiki/index.php/UnRAID_Add_Ons#rsync_.28remote_file_sync.29 rsync is included  Is this through GUI or command line?

4)  What kind of read/write performance could I expect with 5 or 6 7200 rpm drives (either WD black or WD SE NAS), a Core i3 (possibly i5 if it makes sense?) and 8GB RAM?  Would just a single NIC (no LACP) hold this system back?

 

Thanks,

 

->g.

1)  Dual parity support?  I believe the first time I came across unRAID this feature was being considered.  Whatever happened to it?

Still planned.

2)  Is LACP and VLAN trunking/tagging supported?  From what I can gather on the forum LACP is and turnking is not but I haven't seen any recent webGUI pics or an official detailed feature list.

LACP is in the GUI. VLAN is done in the switch.

3)  According to here http://lime-technology.com/wiki/index.php/UnRAID_Add_Ons#rsync_.28remote_file_sync.29 rsync is included  Is this through GUI or command line?

CLI

4)  What kind of read/write performance could I expect with 5 or 6 7200 rpm drives (either WD black or WD SE NAS), a Core i3 (possibly i5 if it makes sense?) and 8GB RAM?  Would just a single NIC (no LACP) hold this system back?

40-60 Mbps on writes directly to the array. Writes to a cache drive and reads should be limited by the particular disks performance. LACP will not allows a single TCP session to exceed 120MBps. It may be useful if multiple readers are accessing distinct disks.

 

Thanks,

 

->g.

NP

2)  Is LACP and VLAN trunking/tagging supported?  From what I can gather on the forum LACP is and turnking is not but I haven't seen any recent webGUI pics or an official detailed feature list.

LACP is in the GUI. VLAN is done in the switch.

That would make it a host/access port and not a trunk port.  Trunks have to be configured on both ends.

 

4)  What kind of read/write performance could I expect with 5 or 6 7200 rpm drives (either WD black or WD SE NAS), a Core i3 (possibly i5 if it makes sense?) and 8GB RAM?  Would just a single NIC (no LACP) hold this system back?

40-60 Mbps on writes directly to the array. Writes to a cache drive and reads should be limited by the particular disks performance. LACP will not allows a single TCP session to exceed 120MBps. It may be useful if multiple readers are accessing distinct disks.

I assume you mean 40-60 megabytes per second?  That seems slow.  I can basically saturate a single 1GB link on my Synology NAS with one client (and no option for cache disk) at ~100MBps.  Even the Drobo 5N can do 60-70 MBps (and Drobos are known for being slow).  Is this some sort of software limitation with unRAID?

I assume you mean 40-60 megabytes per second?  That seems slow.  I can basically saturate a single 1GB link on my Synology NAS with one client (and no option for cache disk) at ~100MBps.  Even the Drobo 5N can do 60-70 MBps (and Drobos are known for being slow).  Is this some sort of software limitation with unRAID?

 

It is the prime disadvantage with the underlining unRAID design.  See the link for how unRAID works:

 

      http://lime-technology.com/technology/

 

Because it is not a striped drive RAID, there are two writes which muist occur whenever data is written to the array--- The Purity drive and the Data drive where the data is actually stored.  You should understand that most users of unRAID are using it to archive media (music, pictures, video) and that the use from this type of use is write once, read often.  If you need higher write speeds, you can use a cache drive (the speed of the cache drive or your network speed will be the limiting factor in this case) but the data is unprotected until it is actually copied to the array. 

You should understand that most users of unRAID are using it to archive media (music, pictures, video) and that the use from this type of use is write once, read often.  If you need higher write speeds, you can use a cache drive (the speed of the cache drive or your network speed will be the limiting factor in this case) but the data is unprotected until it is actually copied to the array.

Understood.  I would be using it to replace my drobo which right now is just a backup to my Synology.  I recently had the volume crash on my Synology and had to restore my data from my drobo and it was pretty slow going so just looking for something with better performance (and while I'm at it more options).

If by performance you mean read/write speeds, then unRAID is not going to be able to compete with striping. Instead, what you get is the ability to use drives of different sizes and the ability to spin down any drives not being accessed. Any file is stored completely on only one disk so only one disk needs to be spinning to read a file (parity also has to spin and be written when writing the file). If a single drive fails it can be completely rebuilt from parity and the other drives, with everything still accessible during rebuild.

2)  Is LACP and VLAN trunking/tagging supported?  From what I can gather on the forum LACP is and turnking is not but I haven't seen any recent webGUI pics or an official detailed feature list.

 

 

Thanks,

 

->g.

 

LACP is supported,  dot1q tagging isn't out of the box.  Probably the confusion stems from some switch manufacturers referring to link aggregation as trunking. *cough*Netgear*cough*

 

I too am also considering unraid. What concerns me is that there is no protection against bitrot. there are also many people who believe that spinning down your drives can shorten their lifespan. Perhaps this only applies to server related stuff like freenas?

Does unraid support raid10? 

I too am also considering unraid. What concerns me is that there is no protection against bitrot.

 

We have seen no evidence of bitrot being a legitimate problem, but there has been conjecture. It would be quite easy to write a program to read a block and then I mmediately write that exact same block to the exact same location.

 

there are also many people who believe that spinning down your drives can shorten their lifespan. Perhaps this only applies to server related stuff like freenas?

 

Drives on media servers tend to sit idle for weeks even months at a time. We recommend a monthly parity check to ensure the drives are alive and well. It is hard to imagine that a drive sitting spundown for 29 of 30 days a month has a shorter life than one that spins continuously. What is easier to imagine is a very short spindown interval that results in drives spinning up and down many times in normal use patterns. UnRaid gives you full control of how long a drive must be idle before it will spin down. I have mine set at 5 hours. So if a drive spins up it won't spin down again for at least that long.

 

A related concept are load cycle counts (LCCs). These are caused by the drives themselves and on some Western Digital drives can get excessive. There are ways to dramatically reduce their frequency referenced in our forum.

 

Does unraid support raid10?

 

Follow the "What is parity?" link in my sig to understand unRaid's means of controlled array integrity.

 

RAID 10 involves striping data while mirroring each disk. It is a technique that insures high performance and full redundancy. With the right controller card there is no reason you could not implement a RAID 10 configuration on you unRaid server. I have a RAID 1 pair on mine running alongside of unRaid. 

 

But unRaid has a very different goal and philosophy than RAID1 or RAID10. A single parity disk protects the entire array. So, for example, you could have 20 4T disks, that's 88T of data, protected by a single 4T drive. Protecting 20 4T drives with RAID10 would take 20 more 4T drives. RAID5 is not nearly as redundant as RAID10, but involves striping. In a striped array you are subject to loosing all of your data if multiple drives fail or it thinks they have. UnRaid is much more forgiving. In the example above, if one drive failed you'd be able to recover it. And if 2 drives failed the other 18 would still contain all their data. And if a loose cable only made it look like a drive had failed and reconnecting it was the only problem, you'd loose nothing.

 

What do you give up with unRaid. Write performance. I won't go into the details but unRaid writes are not nearly as fast as RAID arrays. So if you want to write an airline reservation system you should not put its database on unRaid. But it is perfectly suited to a large media collection.

 

It is the prime disadvantage with the underlining unRAID design.  See the link for how unRAID works:

 

      http://lime-technology.com/technology/

 

Because it is not a striped drive RAID, there are two writes which muist occur whenever data is written to the array--- The Purity drive and the Data drive where the data is actually stored.  You should understand that most users of unRAID are using it to archive media (music, pictures, video) and that the use from this type of use is write once, read often.  If you need higher write speeds, you can use a cache drive (the speed of the cache drive or your network speed will be the limiting factor in this case) but the data is unprotected until it is actually copied to the array.

 

If by performance you mean read/write speeds, then unRAID is not going to be able to compete with striping. Instead, what you get is the ability to use drives of different sizes and the ability to spin down any drives not being accessed. Any file is stored completely on only one disk so only one disk needs to be spinning to read a file (parity also has to spin and be written when writing the file). If a single drive fails it can be completely rebuilt from parity and the other drives, with everything still accessible during rebuild.

Given these responses it sounds like I would be wasting money then on an all 7200 rpm system and should save the 7200 rpm drives for cache and parity and use something like WD Red NAS drives for data?

 

I have a RAID 1 pair on mine running alongside of unRaid.

You mean on the same server as unRAID but outside of the unRAID OS?  Does unRAID have an option to setup a cache or parity mirror?

Given these responses it sounds like I would be wasting money then on an all 7200 rpm system and should save the 7200 rpm drives for cache and parity and use something like WD Red NAS drives for data?

Unless you do lots of concurrent writes the 7200rpm parity drive could be changed out to WD Red NAS drive as well.  If you want to maximize the speed of your cache drive because of Apps you might consider a SSD instead of a spinner.  If you just want to speed up writes to the array then even the WD Red would out perform the network speed you could get without bonding or 10GB networking.  If the 7200rpm drives you are considering are 800GB platters or less then the Red Nas drives will out perform the 7200rpm drives for large media files.

 

So you might be able skip 7200rpm completely.

Given these responses it sounds like I would be wasting money then on an all 7200 rpm system and should save the 7200 rpm drives for cache and parity and use something like WD Red NAS drives for data?

Unless you do lots of concurrent writes the 7200rpm parity drive could be changed out to WD Red NAS drive as well.  If you want to maximize the speed of your cache drive because of Apps you might consider a SSD instead of a spinner.  If you just want to speed up writes to the array then even the WD Red would out perform the network speed you could get without bonding or 10GB networking.  If the 7200rpm drives you are considering are 800GB platters or less then the Red Nas drives will out perform the 7200rpm drives for large media files.

 

So you might be able skip 7200rpm completely.

Only time there could be significant concurrent writes is during backups which are usually at night when I'm asleep or during the day when I'm working so really doesn't matter I guess.

 

The drives I'm considering are the 3 and 4 TB black and SE NAS (blue).

 

http://www.wdc.com/en/products/products.aspx?id=1050

http://www.wdc.com/en/products/products.aspx?id=760

 

And I don't see anything about platter sizes for those drives on the WDC site.

I have a RAID 1 pair on mine running alongside of unRaid.

You mean on the same server as unRAID but outside of the unRAID OS?  Does unRAID have an option to setup a cache or parity mirror?

 

the unRAID OS is Linux. And my RAID1 pair is mounted in Linux. So it is not outside the UNRAID OS, but is outside the unRAID array.

 

My RAID-1 pair is created by a hardware RAID controller card.  It's actually more complex than that. I have 2 3T 7200 RPM drives attached to the RAID controller, and it creates two logical drives - a 4T RAID0, and a 1T RAID1 pair (1T RAID1 = 2T total storage). If one of the two drives inside the array failed, the 4T RAID0 set is gone, but the 1T RAID1 pair is recoverable.

 

The 4T RAID0 is my parity drive. unRAID just sees it as any other 4T drive. The 1T RAID1 is mounted in my go file. I create custom shares on it for each family member that they use it as primary or backup storage for their computers.  RAID1 is more secure than unRAID, and faster writes too. But the RAID1 slows down when there on writes to the array because they are on the same physical drives as the parity.

 

More details than you wanted, but there you go.

 

unRAID does support a cache drive - a single disk mounted outside of the array by unRAID itself. Although seperate, it is involved in the whole "user share" model. Using it a user can copy files to the server, which are stored on the cache drive. And overnight the files are moved to the protected array. Since the cache is faster the copy is faster from the workstation, but you pay the piper overnight. This was  great boon to unRAID when writes to the protected array screamed along at 10MB/sec. But today, with speeds 3x that fast or more, it is not as important. I have a cache drive but disable the mover script and I copy directly to the array. I'd rather copy it there and not it is parity protected from the start.

 

You can mirror parity if you like. But look at my "What is Parity?" link in my sig and you'll see that parity is not protecting anything. It is parity PLUS every other disk in the array (except one that has failed) that allow you to recover. Loose one and you can't recover anything. So parity is no more of less important than every other disk. In fact it is less important - as it is the one disk that can fail and you have no data to recover.

 

Only time there could be significant concurrent writes is during backups which are usually at night when I'm asleep or during the day when I'm working so really doesn't matter I guess.

 

The drives I'm considering are the 3 and 4 TB black and SE NAS (blue).

 

http://www.wdc.com/en/products/products.aspx?id=1050

http://www.wdc.com/en/products/products.aspx?id=760

 

And I don't see anything about platter sizes for those drives on the WDC site.

 

I would buy drives based on reliability and not performance. You might like a 7200 RPM parity if you want simultaneous writes to go faster, and if both the data drive and parity drive are both 7200 RPM, writes to that data disk will be a little sappier. Look at the BackBlaze drive study to learn about the most and least reliable drives. Hitachi tends to come out on top most of the time.

I have a cache drive but disable the mover script and I copy directly to the array.

So your saying the data gets copied from the cache drive to the array in real time (while data is still being copied to the cache)?

 

I would buy drives based on reliability and not performance. You might like a 7200 RPM parity if you want simultaneous writes to go faster, and if both the data drive and parity drive are both 7200 RPM, writes to that data disk will be a little sappier. Look at the BackBlaze drive study to learn about the most and least reliable drives. Hitachi tends to come out on top most of the time.

Yea I've had good luck with the WD blacks and SEs in my Synology so was planning on sticking with them if I stay with 7200 rpm.  I guess the 7200 rpm drive would only benefit me the most during a drive rebuild then?

Yea I've had good luck with the WD blacks and SEs in my Synology so was planning on sticking with them if I stay with 7200 rpm.  I guess the 7200 rpm drive would only benefit me the most during a drive rebuild then?

 

Yes, or parity check.

 

Since UnRAID is a data repository (vs. an active server) you are not usually going to get much benefit out of the extra cost of the blacks. I have WD green's across the board and can run multiple 1080p movies from the same disk without issue. Parity checks may take me 10 hours instead of 7-8 with blacks, but since I run it once a month overnight, I don't really care. I'd rather invest in more capacity than speed (though I will likely switch to WD Reds for my next drives).

 

So your saying the data gets copied from the cache drive to the array in real time (while data is still being copied to the cache)?

 

No, mover runs overnight. Although I think there is flexibility to schedule it when you want. But you would not want the mover running while the copy to the cache happens - it would defeat the purpose.

 

7200 rpm drive would only benefit me the most during a drive rebuild then?

 

If parity and data are fast, the copy is faster. If parity OR data are slow, the copy will be slower.

 

So there is no reason to buy 7200 RPM data drives if your parity is 5400.

 

But there is a benefit to buy 7200 RPM data drives if parity is 7200.

 

Make sense?

If parity and data are fast, the copy is faster. If parity OR data are slow, the copy will be slower.

 

So there is no reason to buy 7200 RPM data drives if your parity is 5400.

 

But there is a benefit to buy 7200 RPM data drives if parity is 7200.

 

Make sense?

But the reverse is true?  Makes sense to have 7200 rpm parity with 5400 rpm data drives?

If parity and data are fast, the copy is faster. If parity OR data are slow, the copy will be slower.

 

So there is no reason to buy 7200 RPM data drives if your parity is 5400.

 

But there is a benefit to buy 7200 RPM data drives if parity is 7200.

 

Make sense?

But the reverse is true?  Makes sense to have 7200 rpm parity with 5400 rpm data drives?

Now you have hit what I was posting about.  It won't help if you write a single file at a time to your array because when writing to the array the writes happen at the speed of the slowest disk.  When you write multiple files to the array on different disks the faster parity will speed up writes a little because the writes to parity happen faster but there are more of them than to the multiple array drives being written.  But if you are copying files over one at a time - like if mover is moving files from the catch drive to the array - you won't see any speed improvements. 

 

So for example:

PC1 writes to a share on array drive 3.

PC2 writes to a share on array drive 4.

Parity is being updated for the writes from PC1 and PC2 at the same time.  So a faster parity will help.

 

But if you only have:

PC1 writes to a share on array drive 3.

Parity is being updated for the writes from PC1.  So faster parity really doesn't help much here because the writes are proceeding at the slowest speed drive.  The write to parity will be at the faster speed but the data itself is still at the slower speed of drive 3.  Overall you won't see much difference between a faster parity drive and if you had a parity drive running at the same speed as the data drives.

Thanks BobPhoenix I think I got it now.

 

Another question...can a cache drive be added after the fact or does it have to be present when the array is being built for first time?

 

What are the options for managing the cached data?  Can the data move be scheduled at different times?

Cache drive can be added later and removed if needed, for example, to replace another array drive.

 

The mover schedule can be changed in the web interface. Default is daily at 3:40am. I know at least one user who has it set to hourly.

Cache drive can be added later and removed if needed, for example, to replace another array drive.

 

The mover schedule can be changed in the web interface. Default is daily at 3:40am. I know at least one user who has it set to hourly.

What happens when a move is underway and a client pc starts writing data to the array?

Open files are not moved.

Open files are not moved.

But what would it do with the data it was moving when the write started?  Just continue moving it in the background while the new writes occur?

Open files are not moved.

But what would it do with the data it was moving when the write started?  Just continue moving it in the background while the new writes occur?

Yes. I often have NZBs or Torrents going to cache during the time mover runs. Never had any problems. Files that are finished get moved, others stay put until next mover. If looking at the files in a user share, you can't tell whether they are on cache or on the array, since any cached files are part of the share.

The mover moves files. Open files are not moved.

Open files are not moved.

But what would it do with the data it was moving when the write started?  Just continue moving it in the background while the new writes occur?

It depends and yes.

 

http://unix.stackexchange.com/questions/90245/is-using-rsync-while-source-is-being-updated-safe