Perl 6 - the future is here, just unevenly distributed

IRC log for #gluster-dev, 2017-01-12

| Channels | #gluster-dev index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:08 gyadav joined #gluster-dev
02:18 gem joined #gluster-dev
02:28 loadtheacc joined #gluster-dev
02:48 ilbot3 joined #gluster-dev
02:48 Topic for #gluster-dev is now Gluster Development Channel - http://gluster.org | For general chat go to #gluster | Patches - http://review.gluster.org/ | Channel Logs - https://botbot.me/freenode/gluster-dev/ & http://irclog.perlgeek.de/gluster-dev/
02:49 ppai joined #gluster-dev
03:26 atinm_ joined #gluster-dev
03:33 magrawal joined #gluster-dev
03:44 msvbhat joined #gluster-dev
03:49 Shu6h3ndu joined #gluster-dev
03:53 rafi joined #gluster-dev
03:57 shyam joined #gluster-dev
04:19 jiffin joined #gluster-dev
04:25 sanoj joined #gluster-dev
04:25 nbalacha joined #gluster-dev
04:29 t1m1 joined #gluster-dev
04:30 itisravi joined #gluster-dev
04:45 gyadav joined #gluster-dev
04:48 skumar joined #gluster-dev
04:55 ppai joined #gluster-dev
05:11 gyadav_ joined #gluster-dev
05:13 ndarshan joined #gluster-dev
05:15 karthik_us joined #gluster-dev
05:19 rafi joined #gluster-dev
05:21 ankitraj joined #gluster-dev
05:24 hgowtham joined #gluster-dev
05:35 nishanth joined #gluster-dev
05:36 rafi1 joined #gluster-dev
05:42 riyas joined #gluster-dev
05:45 msvbhat joined #gluster-dev
05:51 vimal joined #gluster-dev
05:52 skoduri joined #gluster-dev
05:54 ankitraj joined #gluster-dev
05:54 rafi1 joined #gluster-dev
06:02 aravindavk joined #gluster-dev
06:07 asriram joined #gluster-dev
06:08 AnkitRaj_ joined #gluster-dev
06:09 apandey joined #gluster-dev
06:11 ankitraj joined #gluster-dev
06:11 gyadav joined #gluster-dev
06:15 kotreshhr joined #gluster-dev
06:17 poornima joined #gluster-dev
06:20 apandey joined #gluster-dev
06:20 susant joined #gluster-dev
06:39 ashiq_ joined #gluster-dev
06:44 msvbhat joined #gluster-dev
06:59 asengupt joined #gluster-dev
07:03 k4n0 joined #gluster-dev
07:14 pkalever joined #gluster-dev
07:18 Humble joined #gluster-dev
07:23 rastar joined #gluster-dev
07:27 nishanth joined #gluster-dev
08:03 shyam joined #gluster-dev
08:36 poornima rafi, ping
08:36 rafi poornima: pong
08:36 poornima rafi, regarding the rpc disconnect bug, do you want to take a look
08:54 Saravanakmr joined #gluster-dev
08:58 k4n0 joined #gluster-dev
08:59 hgowtham joined #gluster-dev
09:08 shyam joined #gluster-dev
09:31 msvbhat joined #gluster-dev
09:37 aravindavk joined #gluster-dev
09:47 karthik_us joined #gluster-dev
09:56 rafi joined #gluster-dev
09:57 kotreshhr joined #gluster-dev
10:36 rafi joined #gluster-dev
10:39 rafi1 joined #gluster-dev
10:40 aravindavk_ joined #gluster-dev
10:53 msvbhat joined #gluster-dev
10:54 kotreshhr joined #gluster-dev
10:55 karthik_us joined #gluster-dev
11:15 hgowtham joined #gluster-dev
11:39 k4n0 joined #gluster-dev
12:14 pmisiak joined #gluster-dev
12:14 pmisiak Hi guys, I have a question to glusterfs experts.
12:14 pmisiak how exactly gluster compute brick on which file is stored?
12:14 pmisiak I have a hash computed from the file name and the directory GFID
12:14 pmisiak How gluster knows directory layout? Which brick holds which hash space?
12:14 pmisiak I know it is stored in trusted.glusterfs.dht but does it means that gluster have to read this xattr from every brick to build a hash ring (can't belive in this)?
12:14 pmisiak Or maybe it computes hash ring based on current brick configuration?
12:17 pmisiak let's suppose we have distributed volume without any replication
12:17 pmisiak so every brick holds different hash space
12:50 rastar joined #gluster-dev
12:56 jiffin ndevos: don't we have glusterfs > 3.8.5 available in centossig
12:56 jiffin i can't find any in http://mirror.centos.org/centos​/7/storage/x86_64/gluster-3.8/
12:57 rraja joined #gluster-dev
13:17 kkeithley pmisiak: DHT (distribute) hashes the filename. If you have 4 bricks, the hash % brick-count determines, in the general case, which brick the file is stored on.
13:18 kkeithley If the brick is full then a "pointer" is created on the brick where it should be that points to where it really is.
13:18 kkeithley that's the simplistic answer.
13:19 pkalever joined #gluster-dev
13:26 susant left #gluster-dev
13:32 hgowtham joined #gluster-dev
13:48 ira joined #gluster-dev
13:59 rastar joined #gluster-dev
14:01 pmisiak kkeithley: thanks, what if directory and its layout was created before new bricks addition ?
14:02 pmisiak will DHT compute hash ring based on new bricks count?
14:02 kkeithley rebalance after a brick addtion fixes that
14:02 pmisiak kkeithley: what happens before rebalance?
14:02 shyam joined #gluster-dev
14:02 jiffin1 joined #gluster-dev
14:03 kkeithley and if rebalance has not finished or not run, the hash uses the new brick count. If, e.g., a read can't find it on the brick where it's supposed to be, then it will find it by looking on all the bricks
14:14 pmisiak so hash range from trusted.glusterfs.dht is not used during file lookup ?
14:14 pmisiak it's always computed based on bricks count and optionally bricks sizes
14:17 pmisiak if its true, where trusted.glusterfs.dht is used it is needed or it has only pure informative purpose?
14:19 kkeithley it's for anything that needs to know the brick the file is actually stored on. Gluster knows — by hashing — where the file is.
14:21 pmisiak if I understand this corretly it has to gather trusted.glusterfs.dht from all bricks to know all hash rages and then it know on which brick the file is located
14:23 pkalever left #gluster-dev
14:24 kkeithley huh? No. gluster hashes the filename. hash%brickcount is how gluster knows where the file is.
14:25 pmisiak so why trusted.glusterfs.dht is stored if gluster can so easily compute file location?
14:27 ankitraj joined #gluster-dev
14:27 kkeithley as I indicated, it's so other things that want to know which brick the file is located on can find the file.
14:27 kkeithley other things besides gluster
14:28 ndevos kkeithley: but DHT also takes the size of the bricks into account when assigning hash ranges to directories, right?
14:28 kkeithley I said it was a simplistic explanation
14:29 kkeithley NUFA, e.g. takes brick size into account
14:29 kkeithley IIRC
14:29 ndevos I thought the trusted.glusterfs.dht xattr decides how big the hash range is, and that gets compared to the hashed filename, not just plain hash%brickcount
14:30 kkeithley maybe I'm confusing trusted.glusterfs.dht with something else
14:30 pmisiak http://events.linuxfoundation.jp/sites/​events/files/slides/Vault%202016-%20Glu​sterFS_and_its_distribution_model.pdf page 14
14:30 kkeithley I'll just shut up now. ;-)
14:30 ndevos maybe NUFA uses the xattr and it is a config option for the volume, my dht foo is weak
14:31 pmisiak i think commit hash is also important
14:32 pmisiak BTW. do you know how to see actual commit hash for a volume?
14:33 nbalacha joined #gluster-dev
14:33 pmisiak if directory commit hash == volume commit hash then gluster do not use broadcast to find a file
14:49 pmisiak https://joejulian.name/blog​/dht-misses-are-expensive/
14:50 pmisiak "From this the distribute translator looks to see if it has the mappings for that directory cached. If it doesn't, it queries all the distribute subvolumes for the dht mappings for that directory. Those mappings are stored in extended attributes"
14:50 shaunm joined #gluster-dev
14:50 pmisiak so I think it has to read dht from all bricks to know all hash ranges
14:50 pmisiak and to decide where the file is stored
15:01 kotreshhr left #gluster-dev
15:02 susant joined #gluster-dev
15:02 susant left #gluster-dev
15:23 shyam joined #gluster-dev
15:23 shyam left #gluster-dev
15:25 nbalacha joined #gluster-dev
15:36 ndevos pmisiak: I dont know what a "commit hash" would be... send an email to gluster-devel@gluster.org with your questions/assumptions and one of the DHT developers should be able to reply
15:37 ndevos kkeithley: hows your NLM knowledge in gNFS? I do not think I ever had to look at it...
15:37 ndevos I can reproduce https://bugzilla.redhat.co​m/show_bug.cgi?id=1411344 with glusterfs-3.8.5 from the Storage SIG
15:37 glusterbot Bug 1411344: unspecified, urgent, ---, ndevos, ASSIGNED , [GNFS] GNFS crashed while taking lock on a file from 2 different clients having same volume mounted from 2 different servers
15:39 jiffin joined #gluster-dev
15:39 kkeithley I've never looked at it either.
15:40 ndevos :-/
15:43 ndarshan joined #gluster-dev
15:48 jiffin1 joined #gluster-dev
15:53 riyas joined #gluster-dev
15:55 h4xr joined #gluster-dev
16:06 msvbhat joined #gluster-dev
16:36 msvbhat joined #gluster-dev
17:16 prasanth joined #gluster-dev
17:28 apandey joined #gluster-dev
18:27 vbellur joined #gluster-dev
18:32 apandey joined #gluster-dev
18:43 federicoaguirre joined #gluster-dev
18:48 msvbhat joined #gluster-dev
19:01 prasanth joined #gluster-dev
19:11 purpleidea joined #gluster-dev
19:11 purpleidea joined #gluster-dev
19:15 vbellur joined #gluster-dev
19:17 federicoaguirre Hi there.!
19:17 federicoaguirre I'm having a issue on my cluster.!
19:18 federicoaguirre I've a 2 nodes cluster, both of them are online, one of them are unsynced.!
19:19 federicoaguirre any help would be apreciate
19:29 ankitraj joined #gluster-dev
19:29 federicoaguirre is there a way to force sync?
19:49 AnkitRaj_ joined #gluster-dev
19:50 msvbhat joined #gluster-dev
19:51 vbellur joined #gluster-dev
19:54 annettec joined #gluster-dev
20:00 fam_away joined #gluster-dev
20:39 shaunm joined #gluster-dev
20:39 Humble joined #gluster-dev
21:02 federicoaguirre Hi there..
21:02 federicoaguirre Launching heal operation to perform full self heal on volume storage has been unsuccessful
21:02 federicoaguirre any idea?
21:27 msvbhat joined #gluster-dev
22:40 vbellur joined #gluster-dev
23:31 msvbhat joined #gluster-dev

| Channels | #gluster-dev index | Today | | Search | Google Search | Plain-Text | summary