On Mon, May 05, 2014 at 10:17:38PM +0100, Hugo Mills wrote:
A passing remark I made on this list a day or two ago set me to
thinking. You may all want to hide behind your desks or in a similar
safe place away from the danger zone (say, Vladivostok) at this
point...
If we switch to the
On Thu, May 08, 2014 at 04:58:34PM +0100, Hugo Mills wrote:
The first axis is selection of a suitable device from a list of
candidates. I've renamed things from my last email to try to make
things clearer, but example algorithms here could be:
- first: The old algorithm, which simply
On 05/05/2014 11:17 PM, Hugo Mills wrote:
[...]
Does this all make sense? Are there any other options or features
that we might consider for chunk allocation at this point?
The kind of chunk (DATA, METADATA, MIXED) and the subvolume (when /if this
possibility will come)
As how write
Brendan Hide posted on Mon, 05 May 2014 23:47:17 +0200 as excerpted:
At the moment, we have two chunk allocation strategies: dup and
spread (for want of a better word; not to be confused with the
ssd_spread mount option, which is a whole different kettle of borscht).
The dup allocation
A passing remark I made on this list a day or two ago set me to
thinking. You may all want to hide behind your desks or in a similar
safe place away from the danger zone (say, Vladivostok) at this
point...
If we switch to the NcMsPp notation for replication, that
comfortably describes most
On Mon, May 05, 2014 at 10:17:38PM +0100, Hugo Mills wrote:
Given these four (spread, dup, linear, grouped), I think it's
fairly obvious that spread is a special case of grouped, where each
device is its own group. Then dup is the opposite of grouped (i.e. you
must have one or the other but
On 2014/05/05 11:17 PM, Hugo Mills wrote:
A passing remark I made on this list a day or two ago set me to
thinking. You may all want to hide behind your desks or in a similar
safe place away from the danger zone (say, Vladivostok) at this
point...
I feel like I can brave some mild horrors.
