Mounting ext4 on GhostBSD with fusefs-ext2: what actually works and what does not
Yes, you can mount some ext4 filesystems on GhostBSD using fusefs-ext2, but only under very specific technical conditions. The name of the driver is misleading and many failures come from assuming “ext4” is a single, uniform format. It is not.
Below is a precise breakdown.
1. What fusefs-ext2 really is
fusefs-ext2 is not an ext4 driver.
It is:
• an ext2 implementation
• with partial ext3 support
• with limited, incidental ext4 compatibility
It understands ext4 only insofar as ext4 is backward compatible with ext2/ext3.
Once ext4-only features are used, behavior ranges from read-only fallback to silent failure.
2. ext4 features that usually work
An ext4 filesystem may mount successfully if it meets all of the following conditions.
Filesystem creation example that usually works
mkfs.ext4 -O ^metadata_csum,^64bit,^extent /dev/sdX
or older defaults such as:
mkfs.ext4 -O has_journal /dev/sdX
Supported or tolerated features
These are generally safe:
• 128 byte inodes
• ext3-style journaling (has_journal)
• block sizes ≤ 4 KiB
• directory indexing compatible with ext3
• filesystems originally created as ext3 and later “upgraded”
In practice, this describes older ext4 filesystems or ext4 created explicitly for compatibility.
3. ext4 features that commonly fail
If any of the following are enabled, expect problems.
Features that may prevent mounting entirely
• metadata_csum
• 64bit
• flex_bg (in some layouts)
Features that mount but misbehave
• extents (extent)
• large inodes (256 bytes or more)
• very large directory trees
• heavy use of symlinks
• files larger than 2 TiB
Symptoms include:
• directories appearing empty
• files missing from listings
• I/O errors under load
• kernel messages with no clear error
These failures are often silent, which is the most dangerous part.
4. Journaling behavior (important)
fusefs-ext2 does not implement full ext4 journaling semantics.
What this means in practice:
• Journal replay may not occur correctly
• Dirty filesystems may mount but contain corruption
• Crash consistency is not guaranteed
This makes it unsuitable for:
• databases
• VM images
• long-running writable mounts
5. Performance characteristics
Because this is FUSE:
• All I/O crosses kernel ↔ userland boundaries
• Metadata-heavy workloads are slow
• Large directory scans are noticeably slower
• Concurrent access scales poorly
This is expected behavior, not a bug.
6. Native ext2fs kernel driver comparison
FreeBSD’s kernel driver:
mount -t ext2fs /dev/daXsY /mnt
Despite the name, it can also mount some ext4 filesystems, subject to the same feature restrictions.
Differences:
• kernel space, so faster and more predictable
• fewer moving parts
• still no full ext4 feature support
If both options work, the kernel driver is usually preferable.
7. Concrete “works vs does not work” examples
Works
• External USB disk formatted ext3
• ext4 disk created 10 years ago
• ext4 filesystem created with compatibility flags
• Data recovery from Linux partitions
Does not work reliably
• Modern Linux root filesystems
• ext4 with metadata checksums
• Filesystems created by recent Linux installers
• High churn write workloads
8. What this is good for
Appropriate uses:
• one-off data copy
• reading backups
• inspecting disks from Linux systems
• emergency recovery
9. What this is not for
Inappropriate uses:
• production storage
• long-term writable mounts
• anything requiring crash safety
• performance-sensitive workloads
