Should I still use EXT4 or not?

  • Hi guys,
    I am almost ready to build my first DIY server and have a basic question: should I choose EXT4 for my data drives or not?


    Is EXT4 still good enough or should I look for something more exotic like BTRFS or XFS?


    My scenario:

    • I do not want ZFS
    • I will be using SnapRAID
    • 4x4TB HDD for data, 1 NVMe SSD for docker/applications and one thumb drive for OMV.

    OMV BUILD - MY NAS KILLER - OMV 6.x + omvextrasorg (updated automatically every week)

    NAS Specs: Core i3-8300 - ASRock H370M-ITX/ac - 16GB RAM - Sandisk Ultra Flair 32GB (OMV), 256GB NVME SSD (Docker Apps), Several HDDs (Data) w/ SnapRAID - Fractal Design Node 304 - Be quiet! Pure Power 11 350W


    My all-in-one SnapRAID script!

  • Because you don't know: Yes! You should definitely use EXT4!


    Otherwise you would know exactly why and wouldn't need to ask.

    It makes sense. Thank you :)

    OMV BUILD - MY NAS KILLER - OMV 6.x + omvextrasorg (updated automatically every week)

    NAS Specs: Core i3-8300 - ASRock H370M-ITX/ac - 16GB RAM - Sandisk Ultra Flair 32GB (OMV), 256GB NVME SSD (Docker Apps), Several HDDs (Data) w/ SnapRAID - Fractal Design Node 304 - Be quiet! Pure Power 11 350W


    My all-in-one SnapRAID script!

    • Offizieller Beitrag

    Yes, both BTRFS and ZFS have advanced features that are missing in EXT4. Things like snapshots, copy-on-write, checksums and more. But unless you intend to use these features, and know how to use them, they are useless. And you might just as well use EXT4.


    If you think that you need the advanced features, go ahead and learn how to use them.


    I think BTRFS and ZFS are not "ready", because they lack tools that makes it easy and safe for normal users to use the advanced features. Because of this, unless you really make an effort to learn how to use them safely, they might cause more problems than benefits.

  • Yes, both BTRFS and ZFS have advanced features that are missing in EXT4. Things like snapshots, copy-on-write, checksums and more. But unless you intend to use these features, and know how to use them, they are useless. And you might just as well use EXT4.


    If you think that you need the advanced features, go ahead and learn how to use them.


    I think BTRFS and ZFS are not "ready", because they lack tools that makes it easy and safe for normal users to use the advanced features. Because of this, unless you really make an effort to learn how to use them safely, they might cause more problems than benefits.

    FYI I made the question because I'm coming from a Synology NAS, which uses BTRFS for their Hybrid RAID feature which is quite handy because allows different drives to be pooled together (a bit more flexible than classic RAID, but less than SnapRAID).


    I'm sure the Synology DSM OS does something in the background but I don't use any BTRFS advanced feature like snapshots. Synology really wants you to use BTRFS, but I have no idea why.


    Additionally, I already knew I didn't want to use ZFS due to impact on RAM/performance and the fact I can't extend pools.

    OMV BUILD - MY NAS KILLER - OMV 6.x + omvextrasorg (updated automatically every week)

    NAS Specs: Core i3-8300 - ASRock H370M-ITX/ac - 16GB RAM - Sandisk Ultra Flair 32GB (OMV), 256GB NVME SSD (Docker Apps), Several HDDs (Data) w/ SnapRAID - Fractal Design Node 304 - Be quiet! Pure Power 11 350W


    My all-in-one SnapRAID script!

  • FYI I made the question because I'm coming from a Synology NAS, which uses BTRFS for their Hybrid RAID feature which is quite handy because allows different drives to be pooled together (a bit more flexible than classic RAID, but less than SnapRAID).
    I'm sure the Synology DSM OS does something in the background but I don't use any BTRFS advanced feature like snapshots. Synology really wants you to use BTRFS, but I have no idea why.


    Additionally, I already knew I didn't want to use ZFS due to impact on RAM/performance and the fact I can't extend pools.

    Is the RAM (that you need quite a lot) thing just a FreeNAS thing? Also my understanding was you needed ECC. I decided not to use FreeNAS but when I built my machine I purposely chose a LGA2011 board over a LGA115x board because it could hold more ram and RDIMMs cost significantly less than UDIMMs.

    • Offizieller Beitrag

    Is the RAM (that you need quite a lot) thing just a FreeNAS thing? Also my understanding was you needed ECC. I decided not to use FreeNAS but when I built my machine I purposely chose a LGA2011 board over a LGA115x board because it could hold more ram and RDIMMs cost significantly less than UDIMMs.

    zfs *needs* lots of ram for dedupe (if enabled). zfs will *use* lots of ram for cache if available but it doesn't have to have it. It will be faster with lots of ram. The OS doesn't change anything. FreeNAS (freebsd) is moving to the ZFS on Linux codebase in fact.

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    • Offizieller Beitrag

    Any filesystem benefit from more RAM. It will be used to cache disk access.


    But ZFS has advanced compression features (deduplication) that needs extra RAM, if activated.


    Sometimes there are worried posts about no RAM free. That is because it is all used to cache disk. But if needed the caches can be discarded immediately and used by some app or whatever.

    • Offizieller Beitrag

    Any filesystem benefit from more RAM. It will be used to cache disk access.


    But ZFS has advanced compression features (deduplication) that needs extra RAM, if activated.

    You are correct but zfs will use (and benefit) much more ram than other Linux filesystems.

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • Guys, thank you all for the information you provided.
    I'm sorry to resume such an old discussion, but somebody on Reddit just blew my mind telling me that BTRFS could be the only filesystem supported from OMV6, but I found little information other than this Github issue opened by Votdev itself.
    Do you really think this is going to happen? This would break the vast majority if not ALL OMV installs! It sounds scary.

    OMV BUILD - MY NAS KILLER - OMV 6.x + omvextrasorg (updated automatically every week)

    NAS Specs: Core i3-8300 - ASRock H370M-ITX/ac - 16GB RAM - Sandisk Ultra Flair 32GB (OMV), 256GB NVME SSD (Docker Apps), Several HDDs (Data) w/ SnapRAID - Fractal Design Node 304 - Be quiet! Pure Power 11 350W


    My all-in-one SnapRAID script!

    • Offizieller Beitrag

    Do you really think this is going to happen? This would break the vast majority if not ALL OMV installs! It sounds scary.

    No and even if it did, I said in that issue that I would write a plugin to use other filesystems.

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    • Offizieller Beitrag

    Guys, thank you all for the information you provided.
    I'm sorry to resume such an old discussion, but somebody on Reddit just blew my mind telling me that BTRFS could be the only filesystem supported from OMV6, but I found little information other than this Github issue opened by Votdev itself.
    Do you really think this is going to happen? This would break the vast majority if not ALL OMV installs! It sounds scary.

    I honestly don't.see where this is that big of a deal. Yeah it will kinda suck at first, backing up data, formatting drives to btrfs, then moving data back. Do it once, you're done. I'm just not a huge fan of using plugin for a filesystem.. I'd rather just use whatever is officially supported.


    Mountain out of a molehill, imo.

    • Offizieller Beitrag

    I'm just not a huge fan of using plugin for a filesystem.. I'd rather just use whatever is officially supported.

    Why? Do you use mergerfs? Adding support for a "normal" Linux filesystem is much different than adding support for zfs or luks if that is making you think a plugin is not that great.

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    • Offizieller Beitrag

    Why? Do you use mergerfs? Adding support for a "normal" Linux filesystem is much different than adding support for zfs or luks if that is making you think a plugin is not that great.

    No I don't. I have no issue w/ people who want to use them, it's just a preference that I'd rather use a file system that has native support. See the issue that occurred with mergerfs this past weekend.


    Just preference, that's all.

    • Offizieller Beitrag

    No I don't. I have no issue w/ people who want to use them, it's just a preference that I'd rather use a file system that has native support. See the issue that occurred with mergerfs this past weekend.

    I honestly don't know what native support means. Native filesystems are using the exact same code as the plugins to add support for a filesystem to OMV. And the mergerfs issue was caused by a change to OMV not the plugin. And this happened to an unreleased version of OMV. Have you seen that happen to a stable release?

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    • Offizieller Beitrag

    I honestly don't know what native support means. Native filesystems are using the exact same code as the plugins to add support for a filesystem to OMV. And the mergerfs issue was caused by a change to OMV not the plugin. And this happened to an unreleased version of OMV. Have you seen that happen to a stable release?

    Maybe "official" is a better word than native.


    First, Don't take this personally, this isn't a criticism of your work, this is just a personal opinion. Of course I've not seen it happen with stable releases. Truthfully, it's just something I've always been concerned about when using plugins for file systems. What happens (hypothetically) if in OMV 7, or 8, or whatever.. you decide to drop the plugins supporting those file systems? Then I'm just right back where I am now having to move all my data, format drives, move data back, etc.


    Maybe (likely?) my concerns are misguided, but it's just something I've always thought about when considering snapraid, mergerfs, etc. When OMV goes btrfs, I'll be formatting all my drives to btrfs.

    • Offizieller Beitrag

    Maybe "official" is a better word than native.


    First, Don't take this personally, this isn't a criticism of your work, this is just a personal opinion. Of course I've not seen it happen with stable releases. Truthfully, it's just something I've always been concerned about when using plugins for file systems. What happens (hypothetically) if in OMV 7, or 8, or whatever.. you decide to drop the plugins supporting those file systems? Then I'm just right back where I am now having to move all my data, format drives, move data back, etc.


    Maybe (likely?) my concerns are misguided, but it's just something I've always thought about when considering snapraid, mergerfs, etc. When OMV goes btrfs, I'll be formatting all my drives to btrfs.

    Hard not to take negatively. A mod saying they basically don't trust plugins because support might be dropped doesn't say much for plugins or my work through six major versions of OMV. OMV has dropped support for things like iSCSI (iscsitarget was official OMV) and if OMV dropped support for ext4 and xfs, isn't the same fear you have with plugins dropping support?

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!