Adding file system support to OMV and some other questions

  • Hello devs,


    I recently ran into a problem where if there's no support for some mounted file system in OMV (for example, Paragon's UFSD, which I use for MAC and NTFS drives), OMV not only refuses to create shares but even open the share list without showing the dreaded "Invalid RPC response" error.

    I am myself a PHP developer and did some rough digging into OMV code and found that this is caused by the lack of file system support in OMV itself (Exception raised due to no filesystem implementation). But reading foreign OOP code takes a lot of time. Perhaps a developer could explain me how can I integrate additional file systems into OMV (it does not have to be easy, I like a challenge) ? In exchange, I could contribute some code back to OMV.


    Other questions:

    Is there good reason you do not refer to drives by their UUID (blkid) identifiers instead of volume labels ? Labels aren't really meant to be unique and in my opinion aren't the best way to identify a drive. Also, doesn't OMV already use UUID to mount drives with no label ?


    Thank you in advance.

  • Please have a look into https://github.com/openmediava…iavault/system/filesystem which files need to be implemented. I guess it is enough to implement a backend class like https://github.com/openmediava…esystem/backend/exfat.inc . The most important thing is you need to tell the omv-engined process to load the additional backend, this is done like https://github.com/openmediava…c/60filesystembackend.inc. Simply drop a new file in that directory and call the registerBackend function.



    Is there good reason you do not refer to drives by their UUID (blkid) identifiers instead of volume labels ?

    Yes, BTRFS, see https://github.com/openmediava…tem/backend/btrfs.inc#L39.


    Also, doesn't OMV already use UUID to mount drives with no label ?

    No, OMV only uses by-label, by-id and by-path to get a predictable device file of a filesystem. See https://github.com/openmediava…ystem/filesystem.inc#L453.


    Labels aren't really meant to be unique and in my opinion aren't the best way to identify a drive.

    Sure, but some users wanted to see that feature. Now it's in, so it can not be cut-out anymore.

  • Thank you for your responses.

    BTRFS is an interesting beast of a file system, not sure how widely used it is in the NAS world, but it must be somewhat popular if you have decided to implement it. For software RAID, I personally prefer block device level solutions like mdadm.


    I will see what I can do regarding the file systems.

    And I will need to find a way how to differentiate HFS+ from NTFS as UFSD mounts both as "ufsd", only noting the filesystem type in kernel log. I will update this thread if I have more questions.


    Here is the plugin I wrote to add nilfs2 as a supported filesystem. Maybe it will help too.


    https://github.com/OpenMediaVa…ers/openmediavault-nilfs2

    Thanks. Examples always help, especially when working with foreign code.

  • BTRFS is an interesting beast of a file system, not sure how widely used it is in the NAS world, but it must be somewhat popular if you have decided to implement it. For software RAID, I personally prefer block device level solutions like mdadm.

    There are a few commercial NASes using BTRFS. And btrfs can do quite a few things that other filesystems and mdadm cannot like snapshots (you could use LVM), bit rot detection, compression, etc. btrfs also makes changing raid level much easier than mdadm. It is much more native to Linux than zfs as well.

    omv 5.5.23 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.4.5
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • There are a few commercial NASes using BTRFS. And btrfs can do quite a few things that other filesystems and mdadm cannot like snapshots (you could use LVM), bit rot detection, compression, etc. btrfs also makes changing raid level much easier than mdadm. It is much more native to Linux than zfs as well.

    Thanks for the information. Last time I checked (a while ago, when deciding what solution would be best for my 10 drive RAID6) brtfs wasn't considered mature enough for production RAIDs (especially levels 5 and 6), but I guess it is now if it's being used in hardware NAS'es.

  • brtfs wasn't considered mature enough for production RAIDs (especially levels 5 and 6), but I guess it is now if it's being used in hardware NAS'es.

    There are still people who say 5/6 isn't ready but that hasn't stopped the commerical NASes. And Red Hat dropped support for btrfs in RHEL7 & 8 but just brought it back in Fedora 33 (I think). So, opinions seem to be changing.

    omv 5.5.23 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.4.5
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!