Hi,
If you're a Debian Wheezy user please give the new packages a try.
Thanks
--
Kaleb
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel
On Fri, 2016-01-29 at 18:59 +0530, PankaJ Singh wrote:
> Hi,
>
> Thanks Anoop for the help,
> Would you please tell me when can we expect this new release with
> this bug fix.
>
Please find the corresponding patch posted for mainline at [1]. I am
not sure whether we can back port the same and
- Original Message -
> From: "Raghavendra Gowdappa"
> To: "Vijay Bellur"
> Cc: "Gluster Devel"
> Sent: Thursday, February 4, 2016 11:28:29 AM
> Subject: Re: [Gluster-devel] Non-blocking lock for renames
>
>
>
> - Original Message -
> > From: "Vijay Bellur"
> > To: "Shyamsun
On 02/04/2016 09:38 AM, Vijay Bellur wrote:
On 02/03/2016 11:34 AM, Venky Shankar wrote:
On Wed, Feb 03, 2016 at 09:24:06AM -0500, Jeff Darcy wrote:
Problem is with workloads which know the files that need to be read
without readdir, like hyperlinks (webserver), swift objects etc. These
are two
- Original Message -
> From: "Vijay Bellur"
> To: "Shyamsundar Ranganathan" , "Raghavendra Gowdappa"
>
> Cc: "Gluster Devel"
> Sent: Thursday, February 4, 2016 9:55:04 AM
> Subject: Non-blocking lock for renames
>
> DHT developers,
>
> We introduced a non-blocking lock prior to a re
Hi Willy,
Its great to see your interest in GlusterFS. But due to some changes in the
lookup related area the current lookup-optimize design does not hold good. Do
you have any other areas in GlusterFS that you would like to work on. Please
let us know so that we can help you further.
- Or
DHT developers,
We introduced a non-blocking lock prior to a rename operation in dht and
fail the rename if the lock acquisition is not successful with 3.6. I
ran into an user in IRC yesterday who is affected by this behavior change:
"We're seeing a behavior in Gluster 3.7.x that we did not s
On 02/03/2016 11:34 AM, Venky Shankar wrote:
On Wed, Feb 03, 2016 at 09:24:06AM -0500, Jeff Darcy wrote:
Problem is with workloads which know the files that need to be read
without readdir, like hyperlinks (webserver), swift objects etc. These
are two I know of which will have this problem, whic
On Wed, Feb 03, 2016 at 09:24:06AM -0500, Jeff Darcy wrote:
> > Problem is with workloads which know the files that need to be read
> > without readdir, like hyperlinks (webserver), swift objects etc. These
> > are two I know of which will have this problem, which can't be improved
> > because we d
I missed doing a #startmeeting, so we don't have meeting minutes for
this weeks meeting. I've opened a request with fedora-infra to
manually import the log [1], and I'll update the list with the minutes
once complete.
~kaushal
[1] https://fedorahosted.org/fedora-infrastructure/ticket/5091
On Wed
On 02/03/2016 07:54 PM, Jeff Darcy wrote:
Problem is with workloads which know the files that need to be read
without readdir, like hyperlinks (webserver), swift objects etc. These
are two I know of which will have this problem, which can't be improved
because we don't have metadata, data co-loca
Maybe Shyam and Sakshi (in cc) can be helpful on this topic. They've
been involved in implementation of lookup-optimize.
~kaushal
On Tue, Feb 2, 2016 at 5:10 PM, Willy Soesanto wrote:
> Hi Gluster-Devs,
>
> My name is Willy. I am a final year undergraduate student from Bandung
> Institute of Tec
> Problem is with workloads which know the files that need to be read
> without readdir, like hyperlinks (webserver), swift objects etc. These
> are two I know of which will have this problem, which can't be improved
> because we don't have metadata, data co-located. I have been trying to
> think o
Hi all,
The weekly Gluster community meeting is starting in 1 hour at 12:00 UTC.
The current agenda for the meeting is below. Add any further topics to
the agenda at https://public.pad.fsfe.org/p/gluster-community-meetings
Meeting details:
- location: #gluster-meeting on Freenode IRC
- date: eve
The file data would be located based on its GFID, so before the *first*
lookup/stat for a file, there is no way to know it's GFID.
NOTE: Instead of a name hash the GFID hash is used, to get immunity
against renames and the like, as a name hash could change the location
information for the file (
On 02/03/2016 09:20 AM, Shyam wrote:
On 02/02/2016 06:22 PM, Jeff Darcy wrote:
Background: Quick-read + open-behind xlators are developed to
help
in small file workload reads like apache webserver, tar etc to get the
data of the file in lookup FOP itself. What happens is, when a lookup
FO
16 matches
Mail list logo
