DRBD-Cookbook. Joerg Christian Seubert

The source filesystem was a BtrFS and the copy ran - to save LAN resources - over a TAR that was compressed on the source machine, pushed through an SSH tunnel and decompressed again on the target machine.

      This work took a little over an hour - probably because the file system had many subdirectories.

      After the work on the source file system was finished, among other things it was enlarged to 200 GB, I spontaneously decided to use xfs as the new file system.

      The recovery time was 20 minutes!

      Needless to say, I have been a self-confessed fan of this file system since that time, especially because the throughput has been confirmed in normal operation.

      3.2.4 BtrFS

      The BtrFS - spelled out B-Tree file system and not "Better FS" or even "Butter FS" - follows a completely different approach than the file systems available in the Linux environment so far. It is based partly on the considerations of the ZFS, which was developed about seven years before also by Sun Microsystems (in the meantime merged into ORACLE). It has built-in RAID, volume management, checksum-based protection against data transfer errors, and uses copy-on-write. copy-on-write is a method where a copy is not real until it is changed by one of the parties. As long as all parties involved have not changed their copy, it is sufficient to save the original once - in the respective file system. The integrated RAID system distinguishes between occupied and free data blocks, so when reconstructing a failed RAID volume, only the occupied disk space needs to be mirrored, which saves an enormous amount of time. In addition, this RAID works with larger data blocks than is the case with classic RAID methods. In a RAID1, there is no mirroring of all data blocks of a data carrier - regardless of whether they are occupied or not - but only the occupied blocks are distributed to all available data carriers. In this way, a RAID1 can be formed from an odd number of disks with different capacities without losing storage space. The B-tree structure - after which the file system is named - comes from the central concept of xfs. BtrFS is now used by SuSE as the file system of the future, while RedHat announced in August 2017 that it would discontinue long-term support for BtrFS in RHEL. Whereas so far it has remained with this announcement and for example fedora¹ uses BtrFS quite automatically unless something else is chosen during installation. In addition to the experience described above, the following considerations should be made with regard to using BtrFS on production servers in conjunction with DRBD:

      1 Most Linux servers purchased as 19-inch devices are equipped with a hardware RAID controller. This means that the RAID functionality of BtrFS is not needed here, since the hard disks connected to the RAID array have the same capacity anyway, otherwise the hardware RAID controller will not work properly or the storage space cannot be used.

      2 The copy-on-write functionality explained above adds an additional virtualization layer that is already done by distributing the data to multiple cluster nodes with DRBD. However, a BtrFS array across multiple cluster nodes is not supported.

      3 In certain cases, using BtrFS on a DRBD device makes perfect sense if you don’t want to miss out on the multiple functionalities of BtrFS.

      An example is the possibility to create a snapshot of the file system. You should, however, be careful before automatically creating such snapshots, as this quickly consumes disk space that you might need for other purposes.

      3.2.5 OCFS2

      The Oracle Cluster File System 2 is a file system that enables simultaneous access from several cluster nodes to a disk device in a cluster array (concurrent access), developed by Oracle for open source clusters. The coordination works via the Distributed Lock Manager.

      The required packages are included as of SLES 11 SP3.

      3.2.6 Conclusion

      You should also think very carefully about which file system you want to use during the basic considerations for setting up a cluster. If you have made the wrong decision, it is only possible to change the file system with increased effort. In this book I show a "recipe" (cf. text number 8 - without increasing the LVM volume) how you can help yourself here. However, you must be aware that this can only be achieved with a downtime of the cluster array. If you are comparing the file systems shown here and do not need the special features that OCFS2 or BtrFS bring, xfs is the method of choice.