It looks indeed like some bug with the RDMA protocol implementation. I
tested TCP and it works fine. It's a huge bummer for me because my network
links work pretty solidly at 50Gb/s in RDMA, while IPoIB gives me (on the
best case) less than 30Gb/s :/
Also, I couldn't create a volume with transp
I have rdma capability. Will test and report back. I'm still on v 3.12.
On January 24, 2019 12:54:26 AM EST, Amar Tumballi Suryanarayan
wrote:
>I suspect this is a bug with 'Transport: rdma' part. We have called out
>for
>de-scoping that feature as we are lacking experts in that domain right
>no
I suspect this is a bug with 'Transport: rdma' part. We have called out for
de-scoping that feature as we are lacking experts in that domain right now.
Recommend you to use IPoIB option, and use tcp/socket transport type (which
is default). That should mostly fix all the issues.
-Amar
On Thu, Jan
That really sounds like a bug with the sharding. I'm not using sharding
on my setup and files are writeable (vim) with 2 bytes and no errors
occur.Perhaps the small size is cached until it's large enough to
trigger a write
On Wed, 2019-01-23 at 21:46 -0200, Lindolfo Meira wrote:
> Also I noticed th
Also I noticed that any subsequent write (after the first write with 340
bytes or more), regardless the size, will work as expected.
Lindolfo Meira, MSc
Diretor Geral, Centro Nacional de Supercomputação
Universidade Federal do Rio Grande do Sul
+55 (51) 3308-3139
On Wed, 23 Jan 2019, Lindolfo M
Just checked: when the write is >= 340 bytes, everything works as
supposed. If the write is smaller, the error takes place. And when it
does, nothing is logged on the server. The client, however, logs the
following:
[2019-01-23 23:28:54.554664] W [MSGID: 103046]
[rdma.c:3502:gf_rdma_decode_hea
Hi Jim. Thanks for taking the time.
Sorry I didn't express myself properly. It's not a simple matter of
permissions. Users can write to the volume alright. It's when vim and nano
are used, or when small file writes are performed (by cat or echo), that
it doesn't work. The file is updated with t
Check permissions on the mount. I have multiple dozens of systems
mounting 18 "exports" using fuse and it works for multiple user
read/write based on user access permissions to the mount point space.
/home is mounted for 150+ users plus another dozen+ lab storage spaces.
I do manage user access wit
Am I missing something here? A mere write operation, using vim or nano,
cannot be performed on a gluster volume mounted over fuse! What gives?
Lindolfo Meira, MSc
Diretor Geral, Centro Nacional de Supercomputação
Universidade Federal do Rio Grande do Sul
+55 (51) 3308-3139
