On Thu, Feb 04, 2016 at 11:34:04AM +0530, Shyam wrote:
> 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
>
> Even with compound fops It will still require two sequential network
> operations from dht2. One to MDC and one to DC So I don't think it helps.
There are still two hops, but making it a compound op keeps the
server-to-server communication in the compounding translator (which
should already be
Pranith Kumar Karampuri writes:
> 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,
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
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
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
> 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
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
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
- Original Message -
> From: "Pranith Kumar Karampuri" <pkara...@redhat.com>
> To: "Jeff Darcy" <jda...@redhat.com>
> Cc: "Gluster Devel" <gluster-devel@gluster.org>
> Sent: Tuesday, February 2, 2016 7:52:25 PM
> Subjec
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
FOP is executed, GF_CONTENT_KEY is
On 02/03/2016 11:49 AM, Pranith Kumar Karampuri wrote:
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
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
FOP is executed, GF_CONTENT_KEY is
> 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
> FOP is executed, GF_CONTENT_KEY is added in xdata with max-length and
>
hi,
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
FOP is executed, GF_CONTENT_KEY is added in xdata with max-length and
posix
18 matches
Mail list logo