Also navigate http://download.gluster.org/pub/gluster/glusterfs/3.4/3.4.2/
On Tue, Jun 24, 2014 at 11:23 AM, Humble Devassy Chirammal <
humble.deva...@gmail.com> wrote:
> Hi,
>
> You can fetch sources from
> http://bits.gluster.org/pub/gluster/glusterfs/src/
>
> --Humble
>
>
> On Tue, Jun 24, 20
Hi,
You can fetch sources from
http://bits.gluster.org/pub/gluster/glusterfs/src/
--Humble
On Tue, Jun 24, 2014 at 4:57 AM, Cary Tsai wrote:
> Need to compile and build glusterfs 3.4.2 from source on
> debian 6.0.6 32-bit environment.
> [Indeed I only need glusterrfs-client]
>
> Could not fin
Jeff,
Comments inlined.
- Original Message -
> From: "Jeff Darcy"
> To: "Gluster Devel"
> Sent: Monday, June 23, 2014 6:53:53 PM
> Subject: [Gluster-devel] Plea for reviews
>
> I have several patches queued up for 3.6, which have all passed
> regression tests. Unfortunately, they're a
Need to compile and build glusterfs 3.4.2 from source on
debian 6.0.6 32-bit environment.
[Indeed I only need glusterrfs-client]
Could not find the source from the download site,
1. should I download it from github.com?
2. I download it from github and in INSTALL, it says
run ./configure, but
> 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
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 provided in
> 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 '*',
I have several patches queued up for 3.6, which have all passed
regression tests. Unfortunately, they're all in areas where our
resources are pretty thin, so getting the required +1 reviews
is proving to be a challenge. The patches are as follows:
* For "heterogeneous bricks [1]
http://review.
On Tue, Jun 17, 2014 at 11:49:26AM -0400, Shyamsundar Ranganathan wrote:
> You maybe looking at the problem being fixed here, [1].
>
> On a lookup attribute mismatch was not being healed across
> directories, and this patch attempts to address the same. Currently
> the version of the patch does
On 06/18/2014 10:13 AM, Pranith Kumar Karampuri wrote:
On 06/18/2014 10:11 AM, Atin Mukherjee wrote:
On 06/18/2014 10:04 AM, Pranith Kumar Karampuri wrote:
On 06/18/2014 09:39 AM, Atin Mukherjee wrote:
Pranith,
Regression test mentioned in $SUBJECT failed (testcase : 14 & 16)
Console log c
On Wed, Jun 18, 2014 at 12:45:35PM -0400, Benjamin Turner wrote:
> I re ran the individual test 20 times, re ran the fs mark test suite 10
> times, and re ran the whole fs sanity test suite again and was unable to
> reproduce.
Many thanks for running these tests!
Niels
>
> -b
>
>
> On Tue, Ju
12 matches
Mail list logo
