Any reason why an XFS kernel driver isn't included in the Armbian images?  I'm coming from the RHEL world so I have no idea if it's common for Debian and it's variants to not have XFS support?  I'm kind of baffled. 

root@cubox-i:~# cat /proc/filesystems 
nodev   sysfs
nodev   rootfs
nodev   ramfs
nodev   bdev
nodev   proc
nodev   cpuset
nodev   cgroup
nodev   cgroup2
nodev   tmpfs
nodev   devtmpfs
nodev   debugfs
nodev   securityfs
nodev   sockfs
nodev   pipefs
nodev   rpc_pipefs
nodev   devpts
        ext3
        ext2
        ext4
        vfat
nodev   nfs
nodev   nfs4
nodev   jffs2
nodev   autofs
        fuseblk
nodev   fuse
nodev   fusectl
        f2fs
nodev   mqueue
nodev   ubifs
        btrfs

# mount -t xfs /dev/sda1 /srv/esata
mount: unknown filesystem type 'xfs'

Coming with next update or if you DIY.

https://github.com/igorpecovnik/lib/commit/d76d3f41fc44aa79f350034a4639a0f4a56e7a95

I have no idea if it's common for Debian and it's variants to not have XFS support?

 

Filesystem support is a kernel thingie and not that much related to 'Debian' since Armbian does not rely on Debian's kernel packages but uses its own variants (on most platforms supporting 2 variants -- legacy and vanilla --  and on all containing a lot of fixes/improvements).

 

And there's a pretty good reason that XFS support is disabled in nearly every kernel source tree around we're using: since it led to data corruption and failures back in the days when the 'Linux on ARM' game started (almost a decade ago in the 2.6.x days). So we enable XFS on a 'per request' basis and hope that the person asking for does at least some basic testing and get back to us if problems occur.

 

And there's a pretty good reason that XFS support is disabled in nearly every kernel source tree around we're using: since it led to data corruption and failures back in the days when the 'Linux on ARM' game started (almost a decade ago in the 2.6.x days). So we enable XFS on a 'per request' basis and hope that the person asking for does at least some basic testing and get back to us if problems occur.

 

Its had a history of corrupting data that predates that too. Earlier versions of the xfs fsck-equivalent would take anything that looked like inode information regardless of position in the filesystem and would happily "repair" data inside of disk images, etc.

Interesting.  I'm coming from the Red Hat world where it's become the default filesystem (RHEL 7 and beyond); with RHEL 6 we defaulted to EXT4. 

 

I will just stick with EXT4 on ARM for now.  Thanks for all the information, everyone!