It seems simplest to store child-parent relationships (one to one)
instead of parent-child relationships (one to many). Based on that, I
looked at some info files and saw that we're already using
parent_volname for snapshot stuff. Maybe we need to change
terminology. Let's say that we use
(D) Secondary volumes may not be started and stopped by the user.
Instead, a secondary volume is automatically started or stopped along
with its primary.
Wouldn't it help in some cases to have secondary volumes running while
primary is not running? Some form of maintenance activity.
So . . . about that new functionality. The core idea of data
classification is to apply step 6c repeatedly, with variants of DHT that
do tiering or various other kinds of intelligent placement instead of
the hash-based random placement we do now. NUFA and switch are
already examples of
(E) The user must specify an explicit option to see the status of
secondary volumes. Without this option, secondary volumes are hidden
and status for their constituent bricks will be shown as though they
were (directly) part of the corresponding primary volume.
IIUC, secondary volumes
On 12/02/2014 10:07 AM, Jeff Darcy wrote:
I've been thinking and experimenting around some of the things we need
in this area to support 4.0 features, especially data classification
http://www.gluster.org/community/documentation/index.php/Features/data-classification
Before I suggest anything,
As I read this I assume this is to ease administration, and not to ease
the code complexity mentioned above, right?
The code complexity needs to be eased, but I would assume that is a by
product of this change.
Correct. The goal is an easy-to-understand way for *users* to create
and
On 12/02/2014 08:37 PM, Jeff Darcy wrote:
I've been thinking and experimenting around some of the things we need
in this area to support 4.0 features, especially data classification
http://www.gluster.org/community/documentation/index.php/Features/data-classification
Before I suggest
