> Sounds like a metadata server would fix this!
>
> ( Yes, this is trolling hard. Ignore. ;> )
Fortunately I'm on vacation now, so my head didn't explode. ;)
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://supercolony.gluster.org/mailm
On 27/06/2014, at 8:39 AM, Xavier Hernandez wrote:
> On Thursday 26 June 2014 12:52:13 Dan Lambright wrote:
>> I don't think brick splitting implemented by LVM would affect directory
>> browsing any more than adding an additional brick would,
>>
>
> Yes, splitting a brick in LVM should be the sam
uster Compliance Feature"
Regards,
Vivek
Just a thought.
Shyam
- Original Message -
From: "Dan Lambright"
To: "Jeff Darcy"
Cc: "Gluster Devel"
Sent: Monday, June 23, 2014 4:48:13 PM
Subject: Re: [Gluster-devel] Data classification proposal
A frustrat
On Thursday 26 June 2014 12:52:13 Dan Lambright wrote:
> I don't think brick splitting implemented by LVM would affect directory
> browsing any more than adding an additional brick would,
>
Yes, splitting a brick in LVM should be the same than adding a normal brick.
The main problem I see is tha
split this view for the client in question.
Just a thought.
Shyam
- Original Message -
> From: "Dan Lambright"
> To: "Jeff Darcy"
> Cc: "Gluster Devel"
> Sent: Monday, June 23, 2014 4:48:13 PM
> Subject: Re: [Gluster-devel] Data classif
;
Sent: Thursday, June 26, 2014 12:01:16 PM
Subject: Re: [Gluster-devel] Data classification proposal
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 ha
"
To: "Krishnan Parthasarathi"
Cc: "Gluster Devel"
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
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
> > > 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 be quite la
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:
>
> htt
> 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) an
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 bec
- 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 size
> 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 be quite large. As soon as we impl
Jeff,
- Original Message -
> > 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 specif
> 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 a
uster Devel"
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 su
> 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
Jeff,
I have a few questions regarding the rules syntax and how they apply.
I think this is different in spirit from the discussion Dan has started
and keeping it separate. See questions inline.
- Original Message -
> One of the things holding up our data classification efforts (which inc
> 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
> response. Can you provide an example of why it is necessary and a list
> could not be provi
not do file name filtering, the "filter-condition" option
did. I'm ok with that.
As far as the "user stories" idea goes, that seems like a good next step.
- Original Message -
From: "Jeff Darcy"
To: "Dan Lambright"
Cc: "Gluster Devel&quo
> 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 of bricks/sub-tiers with wild-cards
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 of bricks/sub-tiers with wild-cards '*',
23 matches
Mail list logo
