Hi Chriss,
did you try to downgrade to gluster v6.6 for example ?
Most probably it's the ACL issue I have experienced some time ago.Gluster devs
recommended either a fake acl (for example mounting the volume with acl and run
a find with 'setfacl -m u:root:rw {} \;' to force gluster to reread the
Hey,
ACL is correctly set:
# file: 5aab365f-b1b9-49d0-b011-566bf936a100
# owner: vdsm
# group: kvm
user::rw-
group::rw-
other::---
Doing a setfacl failed due to "Operation not supported", remounting with
acl, too:
[root@node01 ~]# mount -o remount,acl
/rhev/data-center/mnt/glusterSD/node01.
Thanks for replying,
What I just wrote Stahil was:
ACL is correctly set:
# file: 5aab365f-b1b9-49d0-b011-566bf936a100
# owner: vdsm
# group: kvm
user::rw-
group::rw-
other::---
Doing a setfacl failed due to "Operation not supported", remounting with
acl, too:
[root@node01 ~]# mount -o remo
On February 4, 2020 10:54:54 PM GMT+02:00, Christian Reiss
wrote:
>Thanks for replying,
>
>What I just wrote Stahil was:
>
>
>ACL is correctly set:
>
># file: 5aab365f-b1b9-49d0-b011-566bf936a100
># owner: vdsm
># group: kvm
>user::rw-
>group::rw-
>other::---
>
>Doing a setfacl failed due to "Ope
Hey,
during debug level logging on the bricks I got this bit:
[2020-02-05 09:34:11.368305] I [MSGID: 139001]
[posix-acl.c:263:posix_acl_log_permit_denied]
0-ssd_storage-access-control: client:
CTX_ID:096e8723-f941-4e65-9ce6-5a4a03634d02-GRAPH_ID:0-PID:50568-HOST:node03.example.com-PC_NAME:ssd
On February 5, 2020 11:48:36 AM GMT+02:00, Christian Reiss
wrote:
>Hey,
>
>during debug level logging on the bricks I got this bit:
>
>[2020-02-05 09:34:11.368305] I [MSGID: 139001]
>[posix-acl.c:263:posix_acl_log_permit_denied]
>0-ssd_storage-access-control: client:
>CTX_ID:096e8723-f941-4e65
Were you ever able to find a fix for this? I am facing the same problem and
the case is similar to yours. We have a 6 node distributed-replicated
Gluster, due to a network issue all servers got disconnected and upon
recover one of the volumes started giving the same IO error. The files can
be read
On February 24, 2020 1:55:34 PM GMT+02:00, Hesham Ahmed
wrote:
>Were you ever able to find a fix for this? I am facing the same problem
>and
>the case is similar to yours. We have a 6 node distributed-replicated
>Gluster, due to a network issue all servers got disconnected and upon
>recover one o
My issue is with Gluster 6.7 (the default with oVirt 4.3.7) as is the case
with Christian. I still have the failing volume and disks and can share any
information required.
On Mon, Feb 24, 2020 at 6:21 PM Strahil Nikolov
wrote:
> On February 24, 2020 1:55:34 PM GMT+02:00, Hesham Ahmed
> wrote:
On February 24, 2020 5:10:40 PM GMT+02:00, Hesham Ahmed
wrote:
>My issue is with Gluster 6.7 (the default with oVirt 4.3.7) as is the
>case
>with Christian. I still have the failing volume and disks and can share
>any
>information required.
>
>On Mon, Feb 24, 2020 at 6:21 PM Strahil Nikolov
>wro
Hey,
I do not have the faulty cluster anymore; It's a production environment
with HA requirements so I really cant take it down for days or even
worse, weeks.
I am now running of CentOS7 (manual install) with manual Gluster 7.0
installation and current ovirt. So far so good.
Time will tell
In my case I am continuing with oVirt node 4.3.8 based gluster 6.7 for the
time being. I have resolved the issue by manually copying all disk images
to a new gluster volume which took days specially since disks on gluster
still don't support sparse file copy. But the threat of a temporary network
f
On February 24, 2020 7:50:15 PM GMT+02:00, Hesham Ahmed
wrote:
>In my case I am continuing with oVirt node 4.3.8 based gluster 6.7 for
>the
>time being. I have resolved the issue by manually copying all disk
>images
>to a new gluster volume which took days specially since disks on
>gluster
>still
13 matches
Mail list logo
