XFS is a from the ground up journaling filesystem, whereas EXT4 is still a journal tacked on filesystem. That's said EXT4 has caught up to XFS and in some specific cases exceeded its performance but not all.
The short version is it depends on what you are doing both have pros and cons, Here are some short examples If I'm doing a Gluster object store I will always use XFS because Gluster is optimized for XFS, If it's an NFS volume then EXT4 is usually better because of inode compatibility issues which can be worked around in XFS but tank the performance. If I'm using it for temp space for compiles or an ETL, XFS will probably do better because it will reduce the IOPS around the handling of inodes. Extremely large volumes (100TB+ on a SAN or in a RAID) I always will use XFS. Desktop pick the one you know the best, but if undelete is important to you use EXT4 (XFS has no mechanism for undeleting files). if you are dealing with an embedded device that boots off of an SD card or EMMC, XFS if possible because how it handles inodes puts less wear on it over time. High risk of file corruption due to unreliable power or hardware always XFS The long version There is a huge efficiency gain when deleting files in XFS. It's noticeably faster when freeing up space from deleting files; this is because instead of having an inode per block it only creates 1 inode at the beginning of every file as needed for legacy application backward support. Another positive side effect of his formatting an XFS filesystem is faster because it never pre-creates inodes during the formatting process, infact the only thing mkfs.xfs does is create a couple of redundant journals. The 1 inode per file is also the reason XFS puts less wear on SSD's, This difference wont make a noticeable impact on the life of a business class SSD, and probably not in a decent consumed grade SSD, but for SD cards and EMMC being used as a boot device this impact can be huge especially if that device isn't using tmpfs for /tmp or is storing /var on the SSD and is writing a lot of logs and temp files. Risk of file system corruption due to unplanned power outages XFS, because it keeps multiple copies of the journal, ignores the inodes for recovery and generally is self healing. While they both do an amazing job at recovering from this kind of situation, EXT4 still trusts the inodes over its single copy of the journal and as a result is more likely to have significant file corruption issues sooner. fsck.xfs normally only does a comparison of the copies of the journal to fix journal corruption issues and will usually roll back file changes that were incomplete at the time of the power loss. By the way XFS does this automatically when the volumes are mounted if the checksums of the copies of the journal don't match so essentially it's normally a placebo command which you should never need to run unless you are dealing with bad sectors in the physical media. EXT4 handles things way differently on mount and as a result you may need to manually run fsck.ext4 after a power loss to recover and it may not recover as well. Essentially if you want to create and delete files quickly XFS is definitely the way to go, the easiest way you can see this is by deleting a large multi GB file and running the df command multiple times EXT4 will take a few seconds to free the space and XFS will free it immediately. XFS can also be tuned to optimize the performance in general on RAID volumes if it is told some details about the RAID when the filesystem is created. https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_documentation_en-2Dus_red-5Fhat-5Fenterprise-5Flinux_6_html_performance-5Ftuning-5Fguide_s-2Dstorage-2Dxfs&d=DwIFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=J0XUyOuCLK8Iw3r5uS2peX0cFvg-VzKQz417xJp_NKS1rBAJsaP7fmbiyaCWwCz3&s=anjmxPLaNFBFOW2Ma6LUp1D5fZRlbef28388r3x2kAA&e= https://urldefense.proofpoint.com/v2/url?u=https-3A__xfs.org_index.php_XFS-5FFAQ-23Q-3A-5FHow-5Fto-5Fcalculate-5Fthe-5Fcorrect-5Fsunit.2Cswidth-5Fvalues-5Ffor-5Foptimal-5Fperformance&d=DwIFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=J0XUyOuCLK8Iw3r5uS2peX0cFvg-VzKQz417xJp_NKS1rBAJsaP7fmbiyaCWwCz3&s=NaUHHrZJZOKhn5EanoQKy78vFjwVakMN-Cm3kB3NdCw&e= Also XFS has incremental backup capabilities built in, it rudimentary but its there https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_documentation_en-2Dus_red-5Fhat-5Fenterprise-5Flinux_7_html_storage-5Fadministration-5Fguide_xfsbackuprestore&d=DwIFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=J0XUyOuCLK8Iw3r5uS2peX0cFvg-VzKQz417xJp_NKS1rBAJsaP7fmbiyaCWwCz3&s=JsxStjzjv_BahpqpOc2VZyEHPZIn73ex9tpkznid0_s&e= . With NFS always go with EXT4 because NFS isn't compatible with 64bit inodes, so you need to disable a flag with XFS for "inode64" which means on files over 2GB XFS' will need to create multiple inodes instead of 1 at the beginning of the file which hurts it's performance. Some history about XFS was ported from SGI's IRIX in the early 200X's, with some help and funding from IBM and SuSE. Originally XFS on Irix was written by the brother of the guy who wrote Veritas's VXFS (an OEMed version of which was the filesystem for IBM AIX unix and was also commonly used on SUNOS/Solaris) file system and the two are very similar in both the standard and clustered versions ( CXFS https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_CXFS&d=DwIFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=J0XUyOuCLK8Iw3r5uS2peX0cFvg-VzKQz417xJp_NKS1rBAJsaP7fmbiyaCWwCz3&s=FyqS8PmGFhZTLhAnEgXLnozbaJYoXbYM3QN823E0GEQ&e= ist actually still a thing you can buy licences for ). No one has ever admitted it but XFS and VXFS are so similar most people believe the two brothers actually collaborated significantly on both of their development in both the standard and clustered versions, honestly they are nearly identical aside from a few minor tweaks that make them just barely incompatible with each other. At the time when it was ported it was way better than EXT2 and had a lot of advantages over EXT3 which came later. Early on it had slow adoption in North America because Red Hat and the Fedora project did not support it for over a decade before they changed their minds on it. For the first few years the only Linux distribution that supported XFS as a / and or /boot filesystem was SuSE, and it was rock solid out of the gate and the default filesystem on SuSE Linux until Novell gutted their development team. Now things have changed, it's stable on almost every Linux distribution (unless the distribution is doing something very wrong to the kernel) and Red Hat often recommends you use XFS instead of EXT4 in many cases. On Mon, Dec 4, 2023 at 3:04 PM Edward Zuniga <[email protected]> wrote: > Hello, > > We are upgrading our MRI Lab servers and workstations to AlmaLinux 8. We > have used ext4 for the past 10 years, however we are considering using XFS > for its better performance with larger files. Which file system do you use > for your lab? > > Thanks, > Eddie > > -- > Edward A. Zuniga > Senior Research Analyst/CARI MRI Lab Manager > Virginia Commonwealth University > C. Kenneth and Dianne Wright Center for Clinical and Translational Research > Institute for Drug and Alcohol Studies > Collaborative Advanced Research Imaging (CARI) Facility > 203 East Cary Street, Suite 202 > Richmond, Virginia 23219 > Phone: (804) 828-4184 > Fax: (804) 827-2565 > [email protected] >
