Compliance Feature
Regards,
Vivek
Just a thought.
Shyam
- Original Message -
From: Dan Lambright dlamb...@redhat.com
To: Jeff Darcy jda...@redhat.com
Cc: Gluster Devel gluster-devel@gluster.org
Sent: Monday, June 23, 2014 4:48:13 PM
Subject: Re: [Gluster-devel] Data classification proposal
On Wednesday 25 June 2014 11:42:10 Jeff Darcy wrote:
How space will be allocated to each new sub-brick ? some sort of thin-
provisioning or will it be distributed evenly on each split ?
That's left to the user. The latest proposal, based on discussion of
the first, is here:
On 26/06/2014, at 4:54 PM, Dan Lambright wrote:
Implementing brick splitting using LVM would allow you to treat each logical
volume (split) as an independent brick. Each split would have its own
.glusterfs subdirectory. I think this would help with taking snapshots as
well.
Would brick
...@redhat.com
To: Krishnan Parthasarathi kpart...@redhat.com
Cc: Gluster Devel gluster-devel@gluster.org
Sent: Thursday, June 26, 2014 11:13:48 AM
Subject: Re: [Gluster-devel] Data classification proposal
For the short-term, wouldn't it be OK to disallow adding bricks that
is not a multiple
select tier-2
type features/tiering
option tier-retention
- Original Message -
From: Jeff Darcy jda...@redhat.com
To: Gluster Devel gluster-devel@gluster.org
Sent: Friday, May 23, 2014 3:30:39 PM
Subject: [Gluster-devel] Data classification proposal
One of the things
- Original Message -
For the short-term, wouldn't it be OK to disallow adding bricks that
is not a multiple of group-size?
In the *very* short term, yes. However, I think that will quickly
become an issue for users who try to deploy erasure coding because those
group sizes will
On Wednesday 25 June 2014 08:35:05 Jeff Darcy wrote:
For the short-term, wouldn't it be OK to disallow adding bricks that
is not a multiple of group-size?
In the *very* short term, yes. However, I think that will quickly
become an issue for users who try to deploy erasure coding because
If I understand correctly the proposed data-classification
architecture, each server will have a number of bricks that will be
dynamically modified as needed: as more data-classifying conditions
are defined, a new layer of translators will be added (a new DHT or
AFR, or something else) and
Am I right if I understood that the value for media-type is not
interpreted beyond the scope of matching rules? That is to say, we
don't need/have any notion of media-types that type check internally
for forming (sub)volumes using the rules specified.
Exactly. To us it's just an opaque ID.
@gluster.org
Sent: Monday, June 23, 2014 7:11:44 PM
Subject: Re: [Gluster-devel] Data classification proposal
Rather than using the keyword unclaimed, my instinct was to
explicitly list which bricks have not been claimed. Perhaps you
have something more subtle in mind, it is not apparent to me from your
Its possible to express your example using lists if their entries are allowed
to overlap. I see that you wanted a way to express a matrix (overlapping
rules) with gluster's tree-like syntax as backdrop.
A polytree may be a better term than matrix (DAG without cycles), i.e. when
there are
features/tiering
option tier-retention
- Original Message -
From: Jeff Darcy jda...@redhat.com
To: Gluster Devel gluster-devel@gluster.org
Sent: Friday, May 23, 2014 3:30:39 PM
Subject: [Gluster-devel] Data classification proposal
One of the things holding up our data classification
that doesn't eliminate some of these cases in favor of
tiering and nothing else, that would be great.
- Original Message -
From: Jeff Darcy jda...@redhat.com
To: Gluster Devel gluster-devel@gluster.org
Sent: Friday, May 23, 2014 3:30:39 PM
Subject: [Gluster-devel] Data classification
: [Gluster-devel] Data classification proposal
A frustrating aspect of Linux is the complexity of /etc configuration file's
formats (rsyslog.conf, logrotate, cron, yum repo files, etc) In that spirit
I would simplify the select in the data classification proposal (copied
below) to only accept a list
One of the things holding up our data classification efforts (which include
tiering but also other stuff as well) has been the extension of the same
conceptual model from the I/O path to the configuration subsystem and
ultimately to the user experience. How does an administrator define a
15 matches
Mail list logo
