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
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
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
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
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
> 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
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
- 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
>
>
>
>
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
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 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,
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
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
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.
-
- 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
15 matches
Mail list logo