That’s not how fertilization and reproduction work. But I get the point, perfectionism and all.

Does it come in different flavours? I’d like strawberry please.

Trousers.

Tea… m

Source states:

All Human Skin

Where?

E: found it. Tiny spot northeast of Australia.

I don’t see anything wrong with that. That rug really ties the room together

Oooh. Put it in the machine once more? :)

Once again I don’t get the hype.

I’m not sure which clients are used to connect. Perhaps some proof of work challenge for the connecting client to solve first? Anubis does this for http(s) and browsers. I’ve seen it in the wild quite often in the last weeks, so it seems to be effective (until the scrapers learn to use selenium to mimic browsers or so).

Epstein

Thanks.

Since virtiofs has been developed for this scenario, it would be sane to use it for VMs. Thanks for the hint.

I will look into it. Some users had issues to get it running with incus - older unsupported libvirtd versions in the distri. Also dxa isn’t supported, yet. But maybe it is still better than NFS performance wise.

🤷‍♀️ :)

Technical terms should be seen in their respective context. I even know shorts which are a type of trousers.

And yes: bits would fit better than chars.

Moot point. I do not really need the distributed storage part for my scenario. Not right now.

Maybe I start with NFS and explore gluster as soon as storage distribution is needed. Looks like it could be a drop-in eplacement for NFSv3. Since it doesn’t access the block devices directly, I still could use the respective fs’ tool set (I.e. ext4 or btrfs) for maintenance tasks.

Thanks. I will take a closer look into GlusterFS and Ceph.

The use case would be a file storage for anything (text, documents, images, audio and video files). I’d like to share this data among multiple instances and don’t want to store that data multiple times - it is bad for my bank account and I don’t want to keep track of the various redundant file sets. So data and service decoupling.

Service scaling isn’t a requirement. It’s more about different services (some as containers, some as VMs) which should work on the same files, sometimes concurrently.

That jellyfin/arr approach works well and is easy to set up, if all containers access the same docker volume. But it doesn’t when VMs (KVM) or other containers (lxc) come into play. So I can’t use it in this context.

Failover is nice to have. But there is more to it than just the data replication between hosts. It’s not a priority to me right now.

Database replication isn’t required.

Thanks for asking. I left that detail out. An SSD which is attached to the virtualization host via SATA. I plan to use either a LVM2 volume group or a BTRFS with subvolumes to provide the storage pool to Incus/LXC.

Oven has a good time. :]

Twins.