Search results

From kernel 6.5 to at least 6.8 there is an issue with OCFS2 and io_uring that produces IO errors inside the VM. Unfortunately OCFS2 is not well maintained.

There is OCFS2 which can be setup as clustered filesystem on a shared LUN. You need the 6.14 kernel and will get no official support.

With "# ceph-mon --monmap /root/monmap --keyring /etc/pve/priv/ceph.mon.keyring --mkfs -i nextclouda -m 10.0.1.1" you created a new MON database (--mkfs) and removed all info from the old one, not only the monmap. You should have just inserted the new monmap with "ceph-mon -i mon.nextclouda...

"wipefs -a" may be your friend.

Yes, this is sufficient.

AFAIK this is safe. Best would be to remove the VM/CT config file from /etc/pve of the old cluster. You may encounter some issues with the virtual hardware version on the new cluster. VMs (especially Windows) may be picky.

Ich würde als erstes den MDS mds.pox einmal neu starten.

This is not unusual in such a small cluster with such a low number of PGs. The CRUSH algorithm just doe snot have enough pieces to distribute the data evenly. You should increase the number of PGs so that you have at least 100 per OSD.

I would replace the disk now.

Remove this OSD and redeploy it. There may be just a bit error on the disk.

Erasure coding is not usable in such small clusters. You need at least 10 nodes with enough OSDs to do anything meaningful with erasure coding.

Yes, do not mix two different device classes in one pool. You will only get HDD performance.

You need to replace the sdb drive.

Are there any signs in the kernel log about a failure on the device of this OSD?

Is data affected? Are there any PGs not active+clean?

Proxmox does not use DHCP for network configuration. You could remove the IP configuration from vmbr0 and add a local IP on vmbr1 and also point the default gateway to the opnsense VM. You just have to make sure that these changes happen so that Proxmox is still reachable (via opnsense).

Ah, I did not know about Ceph nano. It says that it only exposes S3 which is HTTP. You will not be able to access the Ceph "cluster" running inside this container with anything else.

If a MON has 127.0.0.1 as its IP there is something fundamentally wrong in the setup. The MONs need an IP from Ceph's public_network so that they are reachable from all the other Ceph daemons and the clients.

Do not use HDD only with Ceph.

Are these two separate CephFS volumes? What does "ceph fs status" show? If that's the case you need to specify the fs name with the fs= option to the mount command.