or Connect
AVS › AVS Forum › Video Components › Home Theater Computers › Mfusick's How to build an affordable 30TB Flexraid media server: Information Requested.!
New Posts  All Forums:Forum Nav:

Mfusick's How to build an affordable 30TB Flexraid media server: Information Requested.! - Page 80

post #2371 of 3344
Thread Starter 
You don't need much to get get started. Just buy Flexraid and install it. You do not need WHS at all. It works great on Windows 7 actually (is that what you have ?) so you can just install Flexraid and get set up.

You need to dedicate 1 hard drive to parity (or more) and the parity drive (PPU DRIVE) must be as large as your largest storage drive. Everything on the parity drive will be lost or erased so use and empty drive for parity. You can add full drives as data drives and no data would be lost.
post #2372 of 3344
I have Win 8.1...

Any performance issue with the Parity Drive being an external USB drive? It's just needed for recover, right?

I am thinking of putting a 4TB in my last free slot and a 4TB for Parity external USB 3.0. That would give me a pool of 4/3/3/2 or 12TB with 4TB+ for ripping some Blue (perhaps over 100 movies) plus the 3TB+ I have already loaded and of course my SACD/DVD-A/CD music.
post #2373 of 3344
If you set up flexraid to update every day at say 3pm, but the computer is off every day at 3pm, is it smart enough to update when it is next turned on like windows automatic update for instance?
post #2374 of 3344
Thread Starter 
Quote:
Originally Posted by Hoots View Post

I have Win 8.1...

Any performance issue with the Parity Drive being an external USB drive? It's just needed for recover, right?

I am thinking of putting a 4TB in my last free slot and a 4TB for Parity external USB 3.0. That would give me a pool of 4/3/3/2 or 12TB with 4TB+ for ripping some Blue (perhaps over 100 movies) plus the 3TB+ I have already loaded and of course my SACD/DVD-A/CD music.

Speed. USB drives are slower and this increases your parity calculation time needed.
post #2375 of 3344
Quote:
Originally Posted by Mfusick View Post

Speed. USB drives are slower and this increases your parity calculation time needed.
Latency also. Can't forget about latency. Same reason we don't use thumb drives in raid arrays other than for fun.
post #2376 of 3344
Thread Starter 
Quote:
Originally Posted by DotJun View Post

Latency also. Can't forget about latency. Same reason we don't use thumb drives in raid arrays other than for fun.

This is basically what I was saying but I tried to say it in a single sentence. Latency is the delay in the time interval between the stimulation and response, or how long something is going to take. It's slower on USB than SATA3. That's why USB drives are slower, and if you take the same HDD out of the USB enclosure and install it on the SATA port you get much faster read and write times. I've yet to see a USB HDD external that can do the same speed as the same HDD can directly on a SATA port.

weather that is because of Latency, or some peformance penalty of the USB to sata controller board, or even if it's because the USB drives come formatted less ideally, I guess it does not matter.

You are right. I was being very general by just saying the single sentence I did. "USB drives are slower" I guess it really does not matter why.
post #2377 of 3344
Quote:
Originally Posted by Mfusick View Post

This is basically what I was saying but I tried to say it in a single sentence. Latency is the delay in the time interval between the stimulation and response, or how long something is going to take. It's slower on USB than SATA3. That's why USB drives are slower, and if you take the same HDD out of the USB enclosure and install it on the SATA port you get much faster read and write times. I've yet to see a USB HDD external that can do the same speed as the same HDD can directly on a SATA port.

weather that is because of Latency, or some peformance penalty of the USB to sata controller board, or even if it's because the USB drives come formatted less ideally, I guess it does not matter.

You are right. I was being very general by just saying the single sentence I did. "USB drives are slower" I guess it really does not matter why.

I'm asking because I genuinely don't know in detail how flexraid works, but that being said, my understanding is that it takes parity snapshots, so unlike in "real" RAID where a high latency drive can effect every write operation, won't it just effect the time it takes to update the parity drive? Again, not knowing how flexraid works, is that something that is done in the background or is everything offline while using it? If it's done in the background, (especially during "off" hours) would a 5% or 10% increase in parity write time make a difference to the end user? And again, I'm guessing here, but I would think that the parity data would basically be written in one big sequential chunk, as opposed to a bunch of small random writes, so I would think the latency wouldn't be additive. (ie, if USB3 overhead added 10ms of latency, writing the parity would take 10ms longer, not 10ms*nBytes)

I guess the point I'm getting at, is that I know the latency is real, but I'm not sure if the impact on real world performance in this application is real.
post #2378 of 3344
Why do we continue to talk about "parity time"?

First --- as has been incorrectly stated here during AVS --- your media absolutely IS available during the update, validate and verify calculations. And those calculations take literally no time at all especially if like many people you are adding media only intermittently (once your server has been setup of course).

To illustrate this let me show you my daily updates...

Here is the e-mail I receive almost everyday (this one is from this morning)...



And here is my schedule at FlexRaid...



So it took literally one minute for the new calculation on a day where I didn't add or move much data. And if I had my media/data would have still been available for use. Now arguably validate and verify take a few hours but the media is still available for use including playback. Again, after the initial setup it is ALWAYS available during update, validate and verify.

So really the only time that "parity time" is an issue is during the initial setup when you are building your array for the first time. So we are talking about a few extra hours on a single day throughout the life of your server. I don't know about you but to me this is a non-issue. I am not going to worry about "parity time" or "parity performance" on a single day at the expense of my wallet or overall build.

But that's just me. To each their own.
post #2379 of 3344
Thread Starter 
Well you should not add, change or move data during your parity update process. Specifically, change data the most. So if a USB 4TB drive takes 20 hours to do an update versus say 10 hours or less for a smaller drive on sata port- it's a benefit IMO. Nothing is worse than having all the lights on the front of my server dancing for hours on end and me having to wait to do what I was doing to do. Keeping your calculation time in check, and able to be completed in a time when you are not using the server (like at night when sleeping) is ideal.

You have 2TB drives in your server off sata ports. So for you it's a non issue. But going with a 4TB USB drive and filling that sucker up is going to take super long time. That does not mean you can't do it, or for someone like you it's a big deal. But for someone like me that uses his server a lot more extensively it can be less ideal.

My advice to him never said he could not do it. Just it was not as good. If not as good is still good enough have at it.
post #2380 of 3344
Thanks for the clarification, assassin. That's kinda what I thought, but I didn't want to assume too much.
post #2381 of 3344
You can move data during an update. Just rerun the update when you are done. Again, all of this can happen in the background or at night.

I am sorry I just really don't get this argument at all.
post #2382 of 3344
Quote:
Originally Posted by Mfusick View Post

Well you should not add, change or move data during your parity update process. Specifically, change data the most. So if a USB 4TB drive takes 20 hours to do an update versus say 10 hours or less for a smaller drive on sata port- it's a benefit IMO. Nothing is worse than having all the lights on the front of my server dancing for hours on end and me having to wait to do what I was doing to do. Keeping your calculation time in check, and able to be completed in a time when you are not using the server (like at night when sleeping) is ideal.

You have 2TB drives in your server off sata ports. So for you it's a non issue. But going with a 4TB USB drive and filling that sucker up is going to take super long time. That does not mean you can't do it, or for someone like you it's a big deal. But for someone like me that uses his server a lot more extensively it can be less ideal.

My advice to him never said he could not do it. Just it was not as good. If not as good is still good enough have at it.

So is the latency on a USB3 drive, such that it will double the time needed to write new parity? That's what I'm trying to find out... how big of a difference is it actually going to make?

Also, if you write/modify as extensively as you do, why the choice of snapshot RAID? Wouldn't more traditional RAID be more appropriate?
post #2383 of 3344
Thread Starter 
Quote:
Originally Posted by ajhieb View Post

So is the latency on a USB3 drive, such that it will double the time needed to write new parity? That's what I'm trying to find out... how big of a difference is it actually going to make?

Also, if you write/modify as extensively as you do, why the choice of snapshot RAID? Wouldn't more traditional RAID be more appropriate?

It's not one factor but many.

First- USB drives read and write pretty slow. Although the theoretical spec for USB3.0 is pretty good- the reality is not. USB must get routed through your CPU too, (one of the reasons it's slower) so the performance can be effected by such a process and speed is variable. SATA3 is much faster in reality. So if you are reading and writing at twice the speed for the same amount of data it's going to take half as long, or twice as long depending on what side you are on.

Not really a super big deal. But if you double capacity from 2TB to 4TB now you need to write and read twice as much data with 4TB drives instead of 2TB drives. That's again making it worse.

So in a scenario where you have a USB drive reading and writing at an average of say 50MB sec, and a SATA drive doing twice that at 100MB/sec - and you have 4TB of data per drive rather than 2TB per drive it will literally take you 4 times as long.

That means for someone like Assassin with 2TB drive and 5 hour parity times (when data is added or moved) now becomes 20 hours to do the same thing. 5 hours isn't a problem. That's why he does not get the issue. 20 hours is a problem. And for someone who uses their server often having it running for 20 hours doing parity just sucks. That is why I feel how I do. I think if you are building a flexraid server you should spec it and design with the intention of having worst case scenario parity still able to be completed while you are sleeping and done in the morning so it doesn't effect you.

I can't run MCM on my TV shows and rename them and mess around with all the metadata while parity is running. It will throw off the integrity of the parity process. And running it a second time again when I am done it a pain in the ass too. I'd rather just never have that become a problem because my server is never busy doing it when I might want to use it.

Assassin can feel as he does. He's not wrong. He's just not seeing it how I see it. I'm not making this stuff up either. This is stuff I learned by living it.
post #2384 of 3344
I don't have all 2tb anymore drives fwiw.

And it won't take you nearly that long. That's the point. In your scenario you are assuming a complete rebuild of your parity drive when you quote something like 20 hours. Who does that? That example is simply not real world. Even if you were to add 1 movie a day you are only taking a few minutes extra of update time each night. And since you can do this at night or in the background I fail to see why it's an issue or why you keep talking about it.

And ajhieb makes a good point. If you are really that concerned about corrupting your data you have no business running snapshot mode and really should be running real time mode if you indeed use your server like you say you do.

Put another way if you really use your server like you say you do I guarantee you have changed or moved data during an update, validate or verify. Snapshot has ways of letting you do that. Otherwise flexraid would be so delicate as to not be usable. This further just validates that this issue is really a non issue.
post #2385 of 3344
Quote:
Originally Posted by Mfusick View Post

It's not one factor but many.

First- USB drives read and write pretty slow. Although the theoretical spec for USB3.0 is pretty good- the reality is not. USB must get routed through your CPU too, (one of the reasons it's slower) so the performance can be effected by such a process and speed is variable. SATA3 is much faster in reality.

Yes, I'm aware that USB lacks DMA, but what I'm trying to ascertain is how much faster in reality is SATA compared to USB.

Quote:
So if you are reading and writing at twice the speed for the same amount of data it's going to take half as long, or twice as long depending on what side you are on.

Yeah, I know twice as slow translates to twice as long. I just want to know if it is actually twice as slow. Are the benchmarks to back that up?

Quote:
Not really a super big deal. But if you double capacity from 2TB to 4TB now you need to write and read twice as much data with 4TB drives instead of 2TB drives. That's again making it worse.

So in a scenario where you have a USB drive reading and writing at an average of say 50MB sec, and a SATA drive doing twice that at 100MB/sec - and you have 4TB of data per drive rather than 2TB per drive it will literally take you 4 times as long.

My understanding is that USB3 drives can sustain 100MB/sec writes so I'm not sure where you're getting your numbers.

Quote:
That means for someone like Assassin with 2TB drive and 5 hour parity times (when data is added or moved) now becomes 20 hours to do the same thing.

Okay, now you're just inflating your numbers. Yes of course if you double the amount of data, you're going to double the writes, but we're talking about a fixed scenario here. I only have X amount of data. Even if that changes, I'm still going to have X+Y data, regardless of what drive interface I'm using.

Quote:
I can't run MCM on my TV shows and rename them and mess around with all the metadata while parity is running. It will throw off the integrity of the parity process. And running it a second time again when I am done it a pain in the ass too. I'd rather just never have that become a problem because my server is never busy doing it when I might want to use it.

...which again makes me curious about your choice of snapshot RAID. It seems like it is more of an inconvenience to you than anything else.
post #2386 of 3344
One thing to consider in the USB (3) vs SATA...

USB is a shared bus, vs SATA which is a point to point to bus. Just that fact would make me not choose USB 3 for long term storage. For temporary tasks, it is perfectly fine. But the overhead and signaling issues in a shared bus architecture can be quite crippling. If another USB device misbehaves, the PC will reset the entire bus to recover from that.

In a storage scenario with the above issue? = uh oh.

There is a reason Ethernet hubs were worse than switches... smile.gif
post #2387 of 3344
Quote:
Originally Posted by kapone View Post

One thing to consider in the USB (3) vs SATA...

USB is a shared bus, vs SATA which is a point to point to bus. Just that fact would make me not choose USB 3 for long term storage. For temporary tasks, it is perfectly fine. But the overhead and signaling issues in a shared bus architecture can be quite crippling. If another USB device misbehaves, the PC will reset the entire bus to recover from that.

In a storage scenario with the above issue? = uh oh.

There is a reason Ethernet hubs were worse than switches... smile.gif

That's true, but isn't the USB3 controller is separate from the other USB2 controllers? If one were to make sure that the only thing plugged into the USB3 controller was said hard drive, then you don't have to worry about sharing bandwidth, or other devices misbehaving, right?

To be clear I'm not saying it is a good solution overall, but for the example of using it for a dedicated parity drive for snapshot RAID, it looks to me like it should work fine.
post #2388 of 3344
Quote:
Originally Posted by ajhieb View Post

That's true, but isn't the USB3 controller is separate from the other USB2 controllers? If one were to make sure that the only thing plugged into the USB3 controller was said hard drive, then you don't have to worry about sharing bandwidth, or other devices misbehaving, right?

To be clear I'm not saying it is a good solution overall, but for the example of using it for a dedicated parity drive for snapshot RAID, it looks to me like it should work fine.
No reason it wouldn't work, but is it optimal?

My perspective would be no. And more so for a parity drive. That thing is critical...
post #2389 of 3344
Quote:
Originally Posted by kapone View Post

No reason it wouldn't work, but is it optimal?

My perspective would be no. And more so for a parity drive. That thing is critical...

Definitely not optimal. But is snapshot RAID "optimal" either? If you've already made that concession is it a big leap to go with a USB3 drive?
post #2390 of 3344
Quote:
Originally Posted by ajhieb View Post

Definitely not optimal. But is snapshot RAID "optimal" either? If you've already made that concession is it a big leap to go with a USB3 drive?
Valid point I guess. smile.gif
post #2391 of 3344
IMO snapshot is really ideal for HTPC use. I assume that once you have your media transferred over most people may add a few rips or movies each day at most (on average). So let's say you do this from Noon - Midnight each day. That leaves you 12 hours to run your update in the background from midnight to noon the next day. And since you are updating just a fraction of your static data this really should take at most a few hours regardless of the size of your drives. Also, I should note that it doesn't matter whether you have a single 4TB drive or one hundred 4TB drives ---- the computation time is the same.

Since 99% of your data is static day to day this is where snapshot really is ideal. If you are constantly moving data (like a business with dozens of employees who work almost the entire 24 hour day) then real time is more ideal as you need that "real time" redundancy. But as I said for HTPC use this isn't at all needed and snapshot is much preferred. Again, my opinion of course.
post #2392 of 3344
Quote:
Originally Posted by ajhieb View Post

That's true, but isn't the USB3 controller is separate from the other USB2 controllers? If one were to make sure that the only thing plugged into the USB3 controller was said hard drive, then you don't have to worry about sharing bandwidth, or other devices misbehaving, right?

To be clear I'm not saying it is a good solution overall, but for the example of using it for a dedicated parity drive for snapshot RAID, it looks to me like it should work fine.

I don't know the real answer to your question. For performance, they shouldn't be much different at all http://www.anandtech.com/show/4758/seagates-goflex-desk-4tb-external-hdd-review/2

Things I don't like and that make me uneasy about your proposal
  • External "desktop" series uses an extra wall wart for power
  • Portable series do not come in large enough sizes for my personal parity usage
  • Portable runs a little hotter than desktop, and both run hotter than my internals (though I've not played with fancy enclosures too much)
  • I've had 2 external drives die. I've only stopped using HDDs after their interface was too outdated biggrin.gif (knock-on-wood)
  • I've had externals sleep with the system but not resume with the system
  • I'm not sure how flexraid handles a disappearance of your parity

Also, USB 3 is not shared in 7 series and beyond
post #2393 of 3344
Thread Starter 
Quote:
Originally Posted by kapone View Post

No reason it wouldn't work, but is it optimal?

My perspective would be no. And more so for a parity drive. That thing is critical...


This is basically where I was coming from^

You could use it if you really wanted to do it, but I probably would figure out a more optimal solution. Those external USB and power wires alone drive me crazy.

Funny I have a 4TB Seagate here new in package next to me. I guess I could try it just to see first hand. Thinking no though.
post #2394 of 3344
Quote:
Originally Posted by Mfusick View Post

This is basically where I was coming from^

You could use it if you really wanted to do it, but I probably would figure out a more optimal solution. Those external USB and power wires alone drive me crazy.

Funny I have a 4TB Seagate here new in package next to me. I guess I could try it just to see first hand. Thinking no though.

But the reason you wouldn't use it has nothing to do with speed or "parity time/performance" (which as I have mentioned is really just a ridiculous thing to keep mentioning) and has everything to do with the fact that an external USB device just isn't as reliable, imo, as an internal device. I think that was the point he was trying to make.
post #2395 of 3344
Quote:
Originally Posted by Mfusick View Post

This is basically where I was coming from^

You could use it if you really wanted to do it, but I probably would figure out a more optimal solution. Those external USB and power wires alone drive me crazy.

Funny I have a 4TB Seagate here new in package next to me. I guess I could try it just to see first hand. Thinking no though.

FWIW and MY reason for avoiding external drives: I picked up an external Hitachi 4TB that I was going to use to replace an internal 2TB drive. I moved all the data over then popped it out of the enclosure....guess what....Windows showed the drive as a single 2TB partition plus 2 RAW partitions when moved internally, plugged it back into the Hitachi controller and all was well, remove the controller from in between and the scenario above.

Bill
post #2396 of 3344
Thread Starter 
Quote:
Originally Posted by mrfattbill View Post

FWIW and MY reason for avoiding external drives: I picked up an external Hitachi 4TB that I was going to use to replace an internal 2TB drive. I moved all the data over then popped it out of the enclosure....guess what....Windows showed the drive as a single 2TB partition plus 2 RAW partitions when moved internally, plugged it back into the Hitachi controller and all was well, remove the controller from in between and the scenario above.

Bill

Haha. Learned that a long time ago. biggrin.gif

I always delete the partition and re set it up as GPT disk and format as single large partition before I copy any data over. They come that way to support 32bit and older OS or hardware that only recognize up to 2TB.
post #2397 of 3344
Quote:
Originally Posted by Mfusick View Post

Haha. Learned that a long time ago. biggrin.gif

I always delete the partition and re set it up as GPT disk and format as single large partition before I copy any data over. They come that way to support 32bit and older OS or hardware that only recognize up to 2TB.

I did, it showed up in Windows as a proper useable 4TB drive until I removed the damn controller mad.gif

Bill
post #2398 of 3344
Thread Starter 
Quote:
Originally Posted by mrfattbill View Post

I did, it showed up in Windows as a proper useable 4TB drive until I removed the damn controller mad.gif

Bill

I guess my solution has been better biggrin.gif I always "shuck" it first and put it into a hot swap bay. I don't ever copy to it over the USB.
post #2399 of 3344
Thread Starter 
Quote:
Originally Posted by assassin View Post

But the reason you wouldn't use it has nothing to do with speed or "parity time/performance" (which as I have mentioned is really just a ridiculous thing to keep mentioning) and has everything to do with the fact that an external USB device just isn't as reliable, imo, as an internal device. I think that was the point he was trying to make.

The parity time isn't critical to you. I disagree.

Don't you run validate and verify ? Care to post up you log data from how long that takes you and compare ?

Even if it's once a month I just don't want to wake up and wait all day for process to complete before I can use my server. You can disagree.

This is like the spin down argument. Personally I don't spin down because I don't want that few second delay to access my server pool.

Why is my desire not to suffer anything less than optimal ridiculous? It's not like what I'm talking about is hard to achieve or costs more so I don't understand the resistance. It's just a couple intelligent set up decisions up front and it's never an issue. One simple thing would be not using a slow large USB drive.
post #2400 of 3344
Quote:
Originally Posted by Mfusick View Post

I guess my solution has been better biggrin.gif I always "shuck" it first and put it into a hot swap bay. I don't ever copy to it over the USB.

tongue.gif I learned my lesson, especially since the data was coming from a 5400RPM drive....it was sooooo slow and had to be done twice.

Bill
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Home Theater Computers
AVS › AVS Forum › Video Components › Home Theater Computers › Mfusick's How to build an affordable 30TB Flexraid media server: Information Requested.!