1.6 KiB
1.6 KiB
NAS Storage Notes
Current Issue: XFS Metadata Overhead
The XFS filesystem on /var/lib/multimedia uses ~100GB more than the actual file data due to metadata overhead.
Root Cause
The filesystem was created with advanced features enabled:
rmapbt=1 # Reverse mapping btree - tracks block ownership
reflink=1 # Copy-on-write support
These features add metadata that scales with filesystem size, not file count. On a 5TB filesystem with 700GB of data, this results in ~100GB (~2%) overhead.
Diagnostic Commands
# Compare file data vs filesystem usage
du -sh /var/lib/multimedia # Actual file data
df -h /var/lib/multimedia # Filesystem reports
# Check XFS features
xfs_info /var/lib/multimedia
# Verify block allocation
xfs_db -r -c "freesp -s" /dev/mapper/vg--data-lv--multimedia
Recommendation: LVM + ext4
For media storage (write-once, read-many), ext4 with minimal reserved space offers the lowest overhead:
# Create filesystem with 0% reserved blocks
mkfs.ext4 -m 0 /dev/vg/lv
# Or adjust existing ext4
tune2fs -m 0 /dev/vg/lv
Why ext4 over XFS for this use case
| Consideration | ext4 | XFS (current) |
|---|---|---|
| Reserved space | 0% with -m 0 |
N/A |
| Metadata overhead | ~0.5% | ~2% (with rmapbt) |
| Shrink support | Yes | No |
| Performance for 4K stream | Identical | Identical |
A single 4K remux stream requires ~12 MB/s. Any filesystem handles this trivially.
Migration Path
- Backup data from XFS volumes
- Recreate LVs with ext4 (
mkfs.ext4 -m 0) - Restore data
- Update
/etc/fstabor NixOSfileSystemsconfig