search for: dht_lookup

...lusterfs.so.0(inode_ref+0x19)[0x7f24de234e69] /usr/lib/x86_64-linux-gnu/libglusterfs.so.0(loc_copy+0x4a)[0x7f24de21291a] /usr/lib/x86_64-linux-gnu/glusterfs/3.7.3/xlator/cluster/distribute.so(dht_local_init+0x4b)[0x7f24d851f51b] /usr/lib/x86_64-linux-gnu/glusterfs/3.7.3/xlator/cluster/distribute.so(dht_lookup+0x91)[0x7f24d8550521] /usr/lib/x86_64-linux-gnu/libglusterfs.so.0(syncop_lookup+0x1a2)[0x7f24de258fc2] /usr/lib/x86_64-linux-gnu/glusterfs/3.7.3/xlator/cluster/distribute.so(gf_defrag_fix_layout+0x87)[0x7f24d85289e7] /usr/lib/x86_64-linux-gnu/glusterfs/3.7.3/xlator/cluster/distribute.so(gf_defrag_s...

...>> /usr/lib/x86_64-linux-gnu/libglusterfs.so.0(loc_copy+0x4a)[0x7f24de21291a] >> >> /usr/lib/x86_64-linux-gnu/glusterfs/3.7.3/xlator/cluster/distribute.so(dht_local_init+0x4b)[0x7f24d851f51b] >> >> /usr/lib/x86_64-linux-gnu/glusterfs/3.7.3/xlator/cluster/distribute.so(dht_lookup+0x91)[0x7f24d8550521] >> >> /usr/lib/x86_64-linux-gnu/libglusterfs.so.0(syncop_lookup+0x1a2)[0x7f24de258fc2] >> >> /usr/lib/x86_64-linux-gnu/glusterfs/3.7.3/xlator/cluster/distribute.so(gf_defrag_fix_layout+0x87)[0x7f24d85289e7] >> >> /usr/lib/x86_64-linux-gnu/gl...

...9)[0x7f24de234e69] > /usr/lib/x86_64-linux-gnu/libglusterfs.so.0(loc_copy+0x4a)[0x7f24de21291a] > /usr/lib/x86_64-linux-gnu/glusterfs/3.7.3/xlator/ > cluster/distribute.so(dht_local_init+0x4b)[0x7f24d851f51b] > /usr/lib/x86_64-linux-gnu/glusterfs/3.7.3/xlator/ > cluster/distribute.so(dht_lookup+0x91)[0x7f24d8550521] > /usr/lib/x86_64-linux-gnu/libglusterfs.so.0(syncop_ > lookup+0x1a2)[0x7f24de258fc2] > /usr/lib/x86_64-linux-gnu/glusterfs/3.7.3/xlator/cluster/distribute.so(gf_ > defrag_fix_layout+0x87)[0x7f24d85289e7] > /usr/lib/x86_64-linux-gnu/glusterfs/3.7.3/xlator/cluste...

...f24de21291a] >> >> >> >> >> >> /usr/lib/x86_64-linux-gnu/glusterfs/3.7.3/xlator/cluster/distribute.so(dht_local_init+0x4b)[0x7f24d851f51b] >> >> >> >> >> >> /usr/lib/x86_64-linux-gnu/glusterfs/3.7.3/xlator/cluster/distribute.so(dht_lookup+0x91)[0x7f24d8550521] >> >> >> >> >> >> /usr/lib/x86_64-linux-gnu/libglusterfs.so.0(syncop_lookup+0x1a2)[0x7f24de258fc2] >> >> >> >> >> >> /usr/lib/x86_64-linux-gnu/glusterfs/3.7.3/xlator/cluster/distribute.so(gf_defrag_fix_lay...

...bglusterfs.so.0(loc_copy+ > 0x4a)[0x7f24de21291a] > >> > >> /usr/lib/x86_64-linux-gnu/glusterfs/3.7.3/xlator/ > cluster/distribute.so(dht_local_init+0x4b)[0x7f24d851f51b] > >> > >> /usr/lib/x86_64-linux-gnu/glusterfs/3.7.3/xlator/ > cluster/distribute.so(dht_lookup+0x91)[0x7f24d8550521] > >> > >> /usr/lib/x86_64-linux-gnu/libglusterfs.so.0(syncop_ > lookup+0x1a2)[0x7f24de258fc2] > >> > >> /usr/lib/x86_64-linux-gnu/glusterfs/3.7.3/xlator/ > cluster/distribute.so(gf_defrag_fix_layout+0x87)[0x7f24d85289e7] > >>...

...mes diagnostics.client-log-level DEBUG` and then I saw this in the client mount log the next time it disconnected: [2018-01-24 08:55:19.138810] D [MSGID: 0] [io-threads.c:358:iot_schedule] 0-homes-io-threads: LOOKUP scheduled as fast fop [2018-01-24 08:55:19.138849] D [MSGID: 0] [dht-common.c:2711:dht_lookup] 0-homes-dht: Calling fresh lookup for /vchebii/revtrans/Hircus-XM_018067032.1.pep.align.fas on homes-readdir-ahead-1 [2018-01-24 08:55:19.138928] D [MSGID: 0] [io-threads.c:358:iot_schedule] 0-homes-io-threads: FSTAT scheduled as fast fop [2018-01-24 08:55:19.138958] D [MSGID: 0] [afr-read-txn.c:2...

...9182e0] ))))) 0-: 10.50.80.104:49152: ping timer event already removed [2017-09-20 13:34:23.346070] D [MSGID: 0] [dht-common.c:1002:dht_revalidate_cbk] 0-gv0-dht: revalidate lookup of / returned with op_ret 0 [Structure needs cleaning] [2017-09-20 13:34:23.347612] D [MSGID: 0] [dht-common.c:2699:dht_lookup] 0-gv0-dht: Calling fresh lookup for /tempdir3 on gv0-replicate-0 [2017-09-20 13:34:23.348013] D [MSGID: 0] [client-rpc-fops.c:2936:client3_3_lookup_cbk] 0-stack-trace: stack-address: 0x3fff88001080, gv0-client-1 returned -1 error: No such file or directory [No such file or directory] [2017-09-...

...og-level DEBUG` and then I saw this in the > client mount log the next time it disconnected: > > [2018-01-24 08:55:19.138810] D [MSGID: 0] [io-threads.c:358:iot_schedule] > 0-homes-io-threads: LOOKUP scheduled as fast fop > [2018-01-24 08:55:19.138849] D [MSGID: 0] [dht-common.c:2711:dht_lookup] > 0-homes-dht: Calling fresh lookup for > /vchebii/revtrans/Hircus-XM_018067032.1.pep.align.fas on > homes-readdir-ahead-1 > [2018-01-24 08:55:19.138928] D [MSGID: 0] [io-threads.c:358:iot_schedule] > 0-homes-io-threads: FSTAT scheduled as fast fop > [2018-01-24 08:55:19.138958]...

...I saw this in the > > client mount log the next time it disconnected: > > > > [2018-01-24 08:55:19.138810] D [MSGID: 0] [io-threads.c:358:iot_schedule] > > 0-homes-io-threads: LOOKUP scheduled as fast fop > > [2018-01-24 08:55:19.138849] D [MSGID: 0] [dht-common.c:2711:dht_lookup] > > 0-homes-dht: Calling fresh lookup for > > /vchebii/revtrans/Hircus-XM_018067032.1.pep.align.fas on > > homes-readdir-ahead-1 > > [2018-01-24 08:55:19.138928] D [MSGID: 0] [io-threads.c:358:iot_schedule] > > 0-homes-io-threads: FSTAT scheduled as fast fop > >...

Looks like it is an issue with architecture compatibility in RPC layer (ie, with XDRs and how it is used). Just glance the logs of the client process where you saw the errors, which could give some hints. If you don't understand the logs, share them, so we will try to look into it. -Amar On Wed, Sep 20, 2017 at 2:40 AM, Walter Deignan <WDeignan at uline.com> wrote: > I recently

..."D [MSGID: 0] [dht-common.c:997:dht_revalidate_cbk] 0-video-backup-dht: revalidate lookup of /path returned with op_ret 0 [Invalid argument]" repeated 8 times between [2017-12-21 16:36:37.171846] and [2017-12-21 16:36:37.172225] [2017-12-21 16:36:37.172457] D [MSGID: 0] [dht-common.c:2692:dht_lookup] 0-video-backup-dht: Calling fresh lookup for /path/file.txt on video-backup-client-4 [2017-12-21 16:36:37.173166] D [MSGID: 0] [client-rpc-fops.c:2910:client3_3_lookup_cbk] 0-video-backup-client-4: gfid changed for /path/file.txt [2017-12-21 16:36:37.173212] D [MSGID: 0] [client-rpc-fops.c:2941:cl...

...2013-02-25 19:56:20.623399] W [dht-layout.c:186:dht_layout_search] 0-adata-dht: no subvolume for hash (value) = 2967408968 [2013-02-25 19:56:20.623404] W [dht-selfheal.c:882:dht_selfheal_directory] 0-adata-dht: 1 subvolumes have unrecoverable errors [2013-02-25 19:56:20.623413] E [dht-common.c:1372:dht_lookup] 0-adata-dht: Failed to get hashed subvol for /files/random-file.dat [2013-02-25 19:57:02.780965] W [fuse-bridge.c:292:fuse_entry_cbk] 0-glusterfs-fuse: 3960898: LOOKUP() /files/random-file.dat => -1 (Invalid argument) [2013-02-25 19:57:02.781385] W [dht-layout.c:186:dht_layout_search] 0-adata-d...

I recently compiled the 3.10-5 client from source on a few PPC64 systems running RHEL 7.3. They are mounting a Gluster volume which is hosted on more traditional x86 servers. Everything seems to be working properly except for creating new directories from the PPC64 clients. The mkdir command gives a "Input/output error" and for the first few minutes the new directory is

Adding Poornima to take a look at it and comment. On Tue, Jan 23, 2018 at 10:39 PM, Alan Orth <alan.orth at gmail.com> wrote: > Hello, > > I saw that parallel-readdir was an experimental feature in GlusterFS > version 3.10.0, became stable in version 3.11.0, and is now recommended for > small file workloads in the Red Hat Gluster Storage Server > documentation[2].

I have a ~600tb distributed gluster volume that I want to start using geo replication on. The current volume is on 6 100tb bricks on 2 servers My plan is: 1) copy each of the bricks to a new arrays on the servers locally 2) move the new arrays to the new servers 3) create the volume on the new servers using the arrays 4) fix the layout on the new volume 5) start georeplication (which should be

Hello, I saw that parallel-readdir was an experimental feature in GlusterFS version 3.10.0, became stable in version 3.11.0, and is now recommended for small file workloads in the Red Hat Gluster Storage Server documentation[2]. I've successfully enabled this on one of my volumes but I notice the following in the client mount log: [2018-01-23 10:24:24.048055] W [MSGID: 101174]

..._fortify_fail+0x37)[0x361d0f6ea7] /lib64/libc.so.6[0x361d0f4ec0] /usr/lib64/glusterfs/3.0.3/xlator/protocol/client.so(client_lookup+0x1bd)[0x7ffdc5988b3d] /usr/lib64/glusterfs/3.0.3/xlator/cluster/replicate.so(afr_lookup+0x433)[0x7ffdc5741c13] /usr/lib64/glusterfs/3.0.3/xlator/cluster/distribute.so(dht_lookup+0x20f)[0x7ffdc552d52f] /usr/lib64/libglusterfs.so.0(default_lookup+0xd4)[0x7ffdc6c7e884] /usr/lib64/glusterfs/3.0.3/xlator/performance/io-cache.so(ioc_lookup+0xd4)[0x7ffdc5101aa4] /usr/lib64/glusterfs/3.0.3/xlator/mount/fuse.so(fuse_first_lookup+0x168)[0x7ffdc4eec418] /usr/lib64/glusterfs/3.0.3/xla...