> One more question. I keep hearing about QoS for volumes as a feature.
> How will we guarantee service quality for all the bricks from a single
> server? Even if we weren't doing QoS, we make sure that operations on
> brick doesn't DOS the others. We already keep hearing from users about
> self-he
On Wednesday 17 June 2015 02:21 AM, Kaushal M wrote:
One more question. I keep hearing about QoS for volumes as a feature.
How will we guarantee service quality for all the bricks from a single
server? Even if we weren't doing QoS, we make sure that operations on
brick doesn't DOS the others. We
On 17 Jun 2015, at 07:21, Kaushal M wrote:
> One more question. I keep hearing about QoS for volumes as a feature.
> How will we guarantee service quality for all the bricks from a single
> server? Even if we weren't doing QoS, we make sure that operations on
> brick doesn't DOS the others. We alr
One more question. I keep hearing about QoS for volumes as a feature.
How will we guarantee service quality for all the bricks from a single
server? Even if we weren't doing QoS, we make sure that operations on
brick doesn't DOS the others. We already keep hearing from users about
self-healing caus
> Reading through that, it sounds like a well thought out approach.
Thanks!
> Did you consider a super-lightweight version first, which only has
> a process listening on one port for multiplexing traffic, and then
> passes the traffic to individual processes running on the server?
>
> eg simil
On 15 Jun 2015, at 20:35, Jeff Darcy wrote:
> I've written up some thoughts about how to have multiple bricks sharing a
> single process/port, since this is necessary to support other 4.0 features
> and is likely to be a bit tricky to implement. Comments welcome here:
>
> https://goo.gl/27L9I5
I've written up some thoughts about how to have multiple bricks sharing a
single process/port, since this is necessary to support other 4.0 features and
is likely to be a bit tricky to implement. Comments welcome here:
https://goo.gl/27L9I5
___
Gluste
