Re: [Gluster-devel] Single layout at root (Was EHT / DHT)

OK, no current DHT workaround… Wasn’t there a xlator that would tend to put files on the local brick (maybe with NFS mount)? BR Jan On 2014/11/26, 1:15 AM, "Shyam" wrote: >On 11/25/2014 05:03 PM, Anand Avati wrote: >> >> >> On Tue Nov 25 2014 at 1:28:59 PM Shyam >

Re: [Gluster-devel] EHT / DHT

I could tell you… But Symantec wouldn’t like it….. From: Poornima Gurusiddaiah Date: Wednesday 26 November 2014 at 7:16 AM To: Jan H Holtzhausen Cc: Subject: Re: [Gluster-devel] EHT / DHT Out of curiosity, what back end and deduplication solution are you using? Regards, Poornima From:

Re: [Gluster-devel] EHT / DHT

Out of curiosity, what back end and deduplication solution are you using? Regards, Poornima - Original Message - From: "Jan H Holtzhausen" To: "Anand Avati" , "Shyam" , gluster-devel@gluster.org Sent: Wednesday, November 26, 2014 3:43:36 AM Subject: Re: [Gluster-devel] EHT / DHT

Re: [Gluster-devel] Single layout at root (Was EHT / DHT)

On 11/25/2014 05:03 PM, Anand Avati wrote: On Tue Nov 25 2014 at 1:28:59 PM Shyam mailto:srang...@redhat.com>> wrote: On 11/12/2014 01:55 AM, Anand Avati wrote: > > > On Tue, Nov 11, 2014 at 1:56 PM, Jeff Darcy mailto:jda...@redhat.com> >

Re: [Gluster-devel] EHT / DHT

On Tue Nov 25 2014 at 2:13:43 PM Jan H Holtzhausen wrote: > Yes we have deduplication at the filesystem layer > As things stand, it is not possible to achieve what you are looking for with DHT. By using regexes, you can influence the placement of files relative to other filenames *only within th

Re: [Gluster-devel] EHT / DHT

Yes we have deduplication at the filesystem layer BR Jan From: Anand Avati Date: Wednesday 26 November 2014 at 12:11 AM To: Jan H Holtzhausen , Shyam , Subject: Re: [Gluster-devel] EHT / DHT Unless there is some sort of de-duplication under the covers happening in the brick, or the files

Re: [Gluster-devel] EHT / DHT

Unless there is some sort of de-duplication under the covers happening in the brick, or the files are hardlinks to each other, there is no cache benefit whatsoever by having identical files placed on the same server. Thanks, Avati On Tue Nov 25 2014 at 12:59:25 PM Jan H Holtzhausen wrote: > As

Re: [Gluster-devel] Single layout at root (Was EHT / DHT)

On Tue Nov 25 2014 at 1:28:59 PM Shyam wrote: > On 11/12/2014 01:55 AM, Anand Avati wrote: > > > > > > On Tue, Nov 11, 2014 at 1:56 PM, Jeff Darcy > > wrote: > > > > (Personally I would have > > done this by "mixing in" the parent GFID to the hash calculation,

Re: [Gluster-devel] EHT / DHT

As to the why. Filesystem cache hits. Files with the same name tend to be the same files. Regards Jan On 2014/11/25, 8:42 PM, "Jan H Holtzhausen" wrote: >So in a distributed cluster, the GFID tells all bricks what a files >preceding directory structure looks like? >Where the physical file i

Re: [Gluster-devel] EHT / DHT

So in a distributed cluster, the GFID tells all bricks what a files preceding directory structure looks like? Where the physical file is saved is a function of the filename ONLY. Therefore My requirement should be met by default, or am I being dense? BR Jan On 2014/11/25, 8:15 PM, "Shyam" wro

Re: [Gluster-devel] EHT / DHT

On 11/25/2014 03:11 PM, Jan H Holtzhausen wrote: STILL doesn’t work … exact same file ends up on 2 different bricks … I must be missing something. All I need is for: /directory1/subdirectory2/foo And /directory2/subdirectoryaaa999/foo To end up on the same brick…. This is not possible is what

Re: [Gluster-devel] EHT / DHT

STILL doesn’t work … exact same file ends up on 2 different bricks … I must be missing something. All I need is for: /directory1/subdirectory2/foo And /directory2/subdirectoryaaa999/foo To end up on the same brick…. Jan On 2014/11/25, 8:00 PM, "Jan H Holtzhausen" wrote: >Hmm >Then somethi

Re: [Gluster-devel] EHT / DHT

Hmm Then something is wrong, If I upload 2 identical files, with different paths they only end up on the same server 1/4 of the time (I have 4 bricks). I’ll test the regex quickly. BR Jan On 2014/11/25, 7:55 PM, "Shyam" wrote: >On 11/25/2014 02:28 PM, Jan H Holtzhausen wrote: >> I think I

Re: [Gluster-devel] EHT / DHT

On 11/25/2014 02:28 PM, Jan H Holtzhausen wrote: I think I have it. Unless I’m totally confused, I can hash ONLY on the filename with: glusterfs --volfile-server=a_server --volfile-id=a_volume \ --xlator-option a_volume-dht.extra_hash_regex='.*[/]' \ /a/mountpoint Correct? The has

Re: [Gluster-devel] EHT / DHT

I think I have it. Unless I’m totally confused, I can hash ONLY on the filename with: glusterfs --volfile-server=a_server --volfile-id=a_volume \ --xlator-option a_volume-dht.extra_hash_regex='.*[/]' \ /a/mountpoint Correct? Jan From: Jan H Holtzhausen Date: Tuesday 25 November 2014

Re: [Gluster-devel] EHT / DHT

>Are you referring to something else in your request? Meaning, you want >/myfile, /dir1/myfile and /dir2/dir3/myfile to fall onto the same > bricks/subvolumes and that perchance is what you are looking for? That is EXACTLY what I am looking for. What are my chances? BR Jan

Re: [Gluster-devel] pthread_mutex misusage in glusterd_op_sm

I made a simple fix that address the problem: http://review.gluster.org/9197 Are there other places where the same bug could exist? Anyone familiar with the code would tell? Emmanuel Dreyfus wrote: > in glusterd_op_sm(), we lock and unlock the gd_op_sm_lock mutex. > Unfortunately, locking and

Re: [Gluster-devel] Wrong behavior on fsync of md-cache ?

On 11/25/2014 02:25 PM, Emmanuel Dreyfus wrote: On Tue, Nov 25, 2014 at 01:42:21PM +0100, Xavier Hernandez wrote: It seems to fail only in NetBSD. I'm not sure what priority it has. Emmanuel is trying to create a regression test for new patches that checks all tests in tests/basic, and tests/bas

[Gluster-devel] pthread_mutex misusage in glusterd_op_sm

Hello in glusterd_op_sm(), we lock and unlock the gd_op_sm_lock mutex. Unfortunately, locking and unlocking can happen in different threads (task swap will occur in handelr call). This case is explictely covered by POSIX: the behavior is undefined. http://pubs.opengroup.org/onlinepubs/9699919799

[Gluster-devel] Todays minutes of the Gluster Community Bug Triage meeting

On 11/25/2014 01:41 PM, Niels de Vos wrote: Hi all, Later today we will have an other Gluster Community Bug Triage meeting. Meeting details: - location: #gluster-meeting on Freenode IRC - date: every Tuesday - time: 12:00 UTC, 13:00 CET (in your terminal, run: date -d "12:00 UTC") - agenda: htt

Re: [Gluster-devel] Wrong behavior on fsync of md-cache ?

On Tue, Nov 25, 2014 at 01:42:21PM +0100, Xavier Hernandez wrote: > It seems to fail only in NetBSD. I'm not sure what priority it has. Emmanuel > is trying to create a regression test for new patches that checks all tests > in tests/basic, and tests/basic/ec/quota.t hits this issue. FWIW, I just

Re: [Gluster-devel] Wrong behavior on fsync of md-cache ?

Xavier Hernandez wrote: > An alternative would be to temporarily remove or change this test to > avoid the problem. That would help on that test, but I suspect the same problem is responsible for other spurious failures. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org _

Re: [Gluster-devel] Wrong behavior on fsync of md-cache ?

On 11/25/2014 12:59 PM, Raghavendra Gowdappa wrote: - Original Message - From: "Xavier Hernandez" To: "Raghavendra Gowdappa" Cc: "Gluster Devel" , "Emmanuel Dreyfus" Sent: Tuesday, November 25, 2014 2:05:25 PM Subject: Re: Wrong behavior on fsync of md-cache ? On 11/25/2014 07:38

Re: [Gluster-devel] Wrong behavior on fsync of md-cache ?

- Original Message - > From: "Xavier Hernandez" > To: "Raghavendra Gowdappa" > Cc: "Gluster Devel" , "Emmanuel Dreyfus" > > Sent: Tuesday, November 25, 2014 2:05:25 PM > Subject: Re: Wrong behavior on fsync of md-cache ? > > On 11/25/2014 07:38 AM, Raghavendra Gowdappa wrote: > > ---

Re: [Gluster-devel] Wrong behavior on fsync of md-cache ?

On Tue, Nov 25, 2014 at 09:35:25AM +0100, Xavier Hernandez wrote: > Anyway it seems that there's a difference between linux and NetBSD because > this test only fails on NetBSD. Is it possible that linux's fuse > implementation delays the fsync request until all pending writes have been > answered ?

Re: [Gluster-devel] Wrong behavior on fsync of md-cache ?

On 11/25/2014 07:38 AM, Raghavendra Gowdappa wrote: - Original Message - From: "Xavier Hernandez" To: "Raghavendra Gowdappa" Cc: "Gluster Devel" , "Emmanuel Dreyfus" Sent: Tuesday, November 25, 2014 12:49:03 AM Subject: Re: Wrong behavior on fsync of md-cache ? I think the problem i

Re: [Gluster-devel] setfacl: testfile: Remote I/O error (zfsonlinux, gluster 3.6, CentOS 6.6)

On Tue, Nov 25, 2014 at 11:14:10AM +0530, Kiran Patil wrote: > zfs set acltype=posixacl mnt resolved the issue. Nice find! Could you add that option yoo the ZFS page in the wiki please? http://gluster.org/community/documentation/index.php/GlusterOnZFS Thanks, Niels > > Thanks, > Kiran. >

[Gluster-devel] REMINDER: Gluster Community Bug Triage meeting today at 12:00 UTC

Hi all, Later today we will have an other Gluster Community Bug Triage meeting. Meeting details: - location: #gluster-meeting on Freenode IRC - date: every Tuesday - time: 12:00 UTC, 13:00 CET (in your terminal, run: date -d "12:00 UTC") - agenda: https://public.pad.fsfe.org/p/gluster-bug-triage