I hope you do realize that modern consumer SSDs have a small cache (at least according to  https://www.storagereview.com/review/samsung-860-evo-ssd-review ) and we can't rule out the disks.

Use gluster's top command to view the read (17.2.6) and write (17.2.7) performance of the bricks before (regular usage),  during (high load)  and after the backup (regular usage):

https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.5/html/administration_guide/sect-running_the_volume_top_command



Best Regards,
Strahil Nikolov 

On Sat, Sep 17, 2022 at 17:49, Diego Ercolani
<diego.ercolani@ssis.sm> wrote:
Parameter cluster.choose-local set to off.
I confirm the filesystem of the bricks are all XFS as required.
I started the farm only to accomplish a test bench of oVirt implementation, so I used 3 hosts based on ryzen5 processor desktop environment equipped with 4 DDR (4 32GB modules) and 1 disk for the OS and the others to use as data brick or nfs target. All SATA based, while the OS is installed on an internal M.2 disk.
The node4 as it doesn't require much space as it is the arbiter, uses only the internal M.2 disk.
Every host is equipped with dual channel x520 intel chipset with 2 SFP+ configured with 9000 packet size. Access lan is the management lan (and even the lan used by gluster) the VLAN are the "production" vlans.

node2:
/dev/mapper/glustervg-glhe on /brickhe type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/mapper/glustervg-gv0 on /brickgv0 type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/mapper/glustervg-gv1 on /brickgv1 type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota)

  Devices file mpath_uuid part4-mpath-Samsung_SSD_860_EVO_500GB_S4XBNF0N334942Y PVID 9iyl5761LWcy3AYy36fNcPk0fADjNYtC last seen on /dev/mapper/Samsung_SSD_860_EVO_500GB_S4XBNF0N334942Y4 not found.
  PV /dev/mapper/Samsung_SSD_870_EVO_4TB_S6BCNG0R300064E  VG glustervg        lvm2 [<3.64 TiB / 1.54 TiB free]
  PV /dev/nvme0n1p4                                        VG glustervg        lvm2 [<287.02 GiB / <287.02 GiB free]
  PV /dev/nvme0n1p3                                        VG onn_ovirt-node2  lvm2 [177.15 GiB / <33.71 GiB free]
  PV /dev/mapper/ST4000NM000A-2HZ100_WJG1ZC85              VG daticold          lvm2 [<3.64 TiB / 2.44 TiB free]

node3:
/dev/mapper/glustervg-glhe on /brickhe type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/mapper/glustervg-gv1 on /brickgv1 type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/mapper/glustervg-gv0 on /brickgv0 type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota)

[root@ovirt-node3 ~]# pvscan -v
  PV /dev/sda        VG glustervg        lvm2 [<3.64 TiB / <1.64 TiB free]
  PV /dev/nvme0n1p4  VG glustervg        lvm2 [<287.02 GiB / <187.02 GiB free]
  PV /dev/nvme0n1p3  VG onn_ovirt-node3  lvm2 [177.15 GiB / <33.71 GiB free]
  Total: 3 [4.09 TiB] / in use: 3 [4.09 TiB] / in no VG: 0 [0  ]

node4:
/dev/mapper/onn_ovirt--node4-gluster on /dati type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=64k,sunit=128,swidth=128,noquota)
_______________________________________________
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-leave@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/
List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/PO7D7UJUAZV2KAD2KNFZY3TTZNDUXLSL/