ZOS FS: Bcache enabled filesystem

[xmonader]

As per kds's request to support a new primitive file system that is enabled with Bcache, with a minimum of 0.1TB on HDD combined with a "to be defined" SSD space for caching. This configuration aims to enhance performance by leveraging SSD speeds for frequently accessed data while maintaining the larger storage capacity of HDDs.

It would be great to have two SSD partiions

• a btrfs parition for the cache
• a redundant partition on the SSD, to ensure data integrity and availability

part of https://git.ourworld.tf/tfgrid/circle_engineering/issues/9

[muhamadazmy]

Okay I did some research and I really think since we going to do this we better then move completely to LVM for the following reasons:

• LVM has built in support for cache (using ssds as cache for slower/bigger HDD), it's way better and way less buggy than Bcache according to the internet.
• LVM will also give us control on the HD/Cache ratio per each virtual disk we need to create.
• LVM will allow us to optimally use the full disk space without fragmentation of free space.
• Faster virtual disk performance because we won't use a file on the filesystem as a vdisk anymore

The reason doing the work against LVM instead of bcache (or bcachefs) is that right now we format and use full disk (without a partition table) which means we can't suddenly support either lvm or cache without a full disk wipe and starting over. Hence if we gonna do this anyway, it's better to use LVM for the previous points.

Nodes in runtime can then based on their workloads distribution do a migration from old style storage system to knew style as follows:

• Create a lvm volume group that include all disks of the system
• Create a zos volume that either fully on the ssd physical volume, or uses a cached logical volume
• For each new workloads that requests a new disk a new LV is created
• For subvolumes, we can easily replace them with LVs then format them with btrfs or ext4 this will also solve a lot of quota issues with using pure btrfs subvolumes.

[delandtj]

no lvm .
no everything devmapper

[muhamadazmy]

@delandtj can you give a reason why ? You have been saying that and I searched everywhere and I didn't find any reason why.

If no lvm, what else can we use that can do the same! I mean if lvm that bad or obsolete why people still using it until today, and why there are no alternatives ?

[delandtj]

managing lvm is a pain for dynamic environments. it's not made for that

[muhamadazmy]

But that's a software problem imho. I mean that's something we can automate and improve upon, no? But all the listed features above are really needed in our environment.

Already right now already the storage management is very limited, and no much "management" is done excepting choosing where to create a vdisk file. So i don't LVM is a step down from what we have now, but will gain a lot of control and performance

Also many posts talks about how Bcache is buggy and lvm is better in that matter. Which is the subject of this issue

[xmonader]

no idea how to proceed, kds asked to put that on hold