[ale] Linux 5.0 File-System Benchmarks: Btrfs vs. EXT4 vs. F2FS vs. XFS
Beddingfield, Allen
allen at ua.edu
Thu Jan 10 10:07:22 EST 2019
I'm not sure how you could go about implementing it in a way that "df"
as it currently exists could interpret it. It is a radically different
way of doing things. Each subvolume IS an actual different mountpoint
pointed to the same partition. Each has a separate line in /etc/fstab
I've included an example fstab and mtab from a SLES 12 BtrFS system
below to demonstrate:
FSTAB:
UUID=df56ce66-5c2e-49e4-b54d-1c556d866a45 swap swap defaults 0 0
UUID=0d0bcc24-36b5-4532-9558-2aee4dfdd082 / btrfs defaults 0 0
UUID=0d0bcc24-36b5-4532-9558-2aee4dfdd082 /boot/grub2/i386-pc btrfs
subvol=@/boot/grub2/i386-pc 0 0
UUID=0d0bcc24-36b5-4532-9558-2aee4dfdd082 /boot/grub2/x86_64-efi btrfs
subvol=@/boot/grub2/x86_64-efi 0 0
UUID=0d0bcc24-36b5-4532-9558-2aee4dfdd082 /home btrfs subvol=@/home 0 0
UUID=0d0bcc24-36b5-4532-9558-2aee4dfdd082 /opt btrfs subvol=@/opt 0 0
UUID=0d0bcc24-36b5-4532-9558-2aee4dfdd082 /tmp btrfs subvol=@/tmp 0 0
UUID=0d0bcc24-36b5-4532-9558-2aee4dfdd082 /usr/local btrfs
subvol=@/usr/local 0 0
UUID=0d0bcc24-36b5-4532-9558-2aee4dfdd082 /var/crash btrfs
subvol=@/var/crash 0 0
UUID=0d0bcc24-36b5-4532-9558-2aee4dfdd082 /var/lib/mailman btrfs
subvol=@/var/lib/mailman 0 0
UUID=0d0bcc24-36b5-4532-9558-2aee4dfdd082 /var/lib/named btrfs
subvol=@/var/lib/named 0 0
UUID=0d0bcc24-36b5-4532-9558-2aee4dfdd082 /var/lib/pgsql btrfs
subvol=@/var/lib/pgsql 0 0
UUID=0d0bcc24-36b5-4532-9558-2aee4dfdd082 /var/log btrfs
subvol=@/var/log 0 0
UUID=0d0bcc24-36b5-4532-9558-2aee4dfdd082 /var/opt btrfs
subvol=@/var/opt 0 0
UUID=0d0bcc24-36b5-4532-9558-2aee4dfdd082 /var/spool btrfs
subvol=@/var/spool 0 0
UUID=0d0bcc24-36b5-4532-9558-2aee4dfdd082 /var/tmp btrfs
subvol=@/var/tmp 0 0
UUID=8f7cd674-e5c7-4c9d-9916-b084236666e8 /srv btrfs defaults 0 0
UUID=0d0bcc24-36b5-4532-9558-2aee4dfdd082 /.snapshots btrfs
subvol=@/.snapshots 0 0
MTAB:
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
devtmpfs /dev devtmpfs rw,nosuid,size=1957856k,nr_inodes=489464,mode=755 0 0
securityfs /sys/kernel/security securityfs
rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts
rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,nodev,mode=755 0 0
tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0
cgroup /sys/fs/cgroup/systemd cgroup
rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd
0 0
pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0
cgroup /sys/fs/cgroup/cpu,cpuacct cgroup
rw,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0
cgroup /sys/fs/cgroup/devices cgroup
rw,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /sys/fs/cgroup/net_cls,net_prio cgroup
rw,nosuid,nodev,noexec,relatime,net_cls,net_prio 0 0
cgroup /sys/fs/cgroup/perf_event cgroup
rw,nosuid,nodev,noexec,relatime,perf_event 0 0
cgroup /sys/fs/cgroup/memory cgroup
rw,nosuid,nodev,noexec,relatime,memory 0 0
cgroup /sys/fs/cgroup/hugetlb cgroup
rw,nosuid,nodev,noexec,relatime,hugetlb 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
cgroup /sys/fs/cgroup/pids cgroup rw,nosuid,nodev,noexec,relatime,pids 0 0
cgroup /sys/fs/cgroup/cpuset cgroup
rw,nosuid,nodev,noexec,relatime,cpuset 0 0
cgroup /sys/fs/cgroup/freezer cgroup
rw,nosuid,nodev,noexec,relatime,freezer 0 0
/dev/sda2 / btrfs rw,relatime,space_cache,subvolid=257,subvol=/@ 0 0
systemd-1 /proc/sys/fs/binfmt_misc autofs
rw,relatime,fd=25,pgrp=1,timeout=0,minproto=5,maxproto=5,direct 0 0
hugetlbfs /dev/hugepages hugetlbfs rw,relatime 0 0
mqueue /dev/mqueue mqueue rw,relatime 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
/dev/sda2 /tmp btrfs rw,relatime,space_cache,subvolid=262,subvol=/@/tmp 0 0
/dev/sda2 /opt btrfs rw,relatime,space_cache,subvolid=261,subvol=/@/opt 0 0
/dev/sdb1 /srv btrfs rw,relatime,space_cache,subvolid=257,subvol=/@ 0 0
/dev/sda2 /var/lib/pgsql btrfs
rw,relatime,space_cache,subvolid=267,subvol=/@/var/lib/pgsql 0 0
/dev/sda2 /var/tmp btrfs
rw,relatime,space_cache,subvolid=271,subvol=/@/var/tmp 0 0
/dev/sda2 /usr/local btrfs
rw,relatime,space_cache,subvolid=263,subvol=/@/usr/local 0 0
/dev/sda2 /home btrfs
rw,relatime,space_cache,subvolid=260,subvol=/@/home 0 0
/dev/sda2 /boot/grub2/x86_64-efi btrfs
rw,relatime,space_cache,subvolid=259,subvol=/@/boot/grub2/x86_64-efi 0 0
/dev/sda2 /var/lib/named btrfs
rw,relatime,space_cache,subvolid=266,subvol=/@/var/lib/named 0 0
/dev/sda2 /var/crash btrfs
rw,relatime,space_cache,subvolid=264,subvol=/@/var/crash 0 0
/dev/sda2 /var/opt btrfs
rw,relatime,space_cache,subvolid=269,subvol=/@/var/opt 0 0
/dev/sda2 /boot/grub2/i386-pc btrfs
rw,relatime,space_cache,subvolid=258,subvol=/@/boot/grub2/i386-pc 0 0
/dev/sda2 /var/lib/mailman btrfs
rw,relatime,space_cache,subvolid=265,subvol=/@/var/lib/mailman 0 0
/dev/sda2 /var/log btrfs
rw,relatime,space_cache,subvolid=268,subvol=/@/var/log 0 0
/dev/sda2 /var/spool btrfs
rw,relatime,space_cache,subvolid=270,subvol=/@/var/spool 0 0
/dev/sda2 /.snapshots btrfs
rw,relatime,space_cache,subvolid=276,subvol=/@/.snapshots 0 0
tracefs /sys/kernel/debug/tracing tracefs rw,relatime 0 0
tmpfs /run/user/0 tmpfs rw,nosuid,nodev,relatime,size=393608k,mode=700 0 0
tmpfs /run/user/21470 tmpfs
rw,nosuid,nodev,relatime,size=393608k,mode=700,uid=21470,gid=100 0 0
On 1/10/19 8:59 AM, DJ-Pfulio via Ale wrote:
> There are pros and cons to upgrading existing utilities to handle ´new´ things.
> fdisk was upgraded to handle GPT, but there was a time, a confusing time, where
> fdisk didn´t work.
>
> Same for grub.
>
> ip is a step backwards in my mind. ifconfig should have been upgraded. Having
> ip put out machine readable, but not human readable output is a failure, IMHO.
>
> df and du are extremely important. Any file system that can provide reasonable
> hooks for df and du to give the truth is a failure, again, IMHO.
>
> Change to interfaces for the sake of change is a bad reason. systemd did this.
> They should have made it backwards compatible. Heck, if MSFT powershell can
> use Unix commands, why can btrfs?
>
>
>
>
>
> On 1/10/19 9:41 AM, Beddingfield, Allen via Ale wrote:
>> The "df" output is annoying, but I'm not sure why it would be a showstopper. It
>> is easy enough to still make sense of.
>>
>> I think it is just a matter of "df" being so old that it can't account for
>> BtrFS. Just because an old utility has trouble interpreting something written
>> many years later, I'm not going to rule out the new thing. (This very argument
>> got heated on the SUSE beta list for SLES 15 about dropping ipconfig for the
>> same reason - it is too old to interpret data accurately from all modern configs).
>>
>> However, BtrFS introduces so much added complication and things that can go
>> wrong that I use it very sparingly. Even though it is the out-of-the-box
>> default FS on SLES, I tend to use XFS for simplicity.
>> Allen B.
>>
>> On 1/10/19 6:47 AM, Jim Kinney via Ale wrote:
>>> Inability to reduce xfs partition size is it's only problem. I've hit size
>>> limit for ext4. The (newly realized for me) issue of df being screwy with
>>> btrfs is a showstopper.
>>>
>>> I've always mitigated performance issues with more spindles. Now it's nvme for
>>> journals and cache.
>>>
>>> At an oracle training (sales pitch), they showed specs on a specific
>>> configuration with really good numbers. Basically indexes were stored on raid1
>>> nvme and data on spinning rust. Makes complicated joins screaming fast.
>>> Postresql can do it too.
>>>
>>> On January 9, 2019 8:56:30 PM EST, DJ-Pfulio via Ale <ale at ale.org> wrote:
>>>
>>> F2FS did well in that comparison. Surprising.
>>> Been using ext4 for almost everything for years. Sometimes being able
>>> to reduce a file system is handy.
>>>
>>> When I learned that btrfs lied to df and du, I was out.
>>>
>>> On 1/9/19 8:41 PM, Raj Wurttemberg via Ale wrote:
>>>
>>> I saw that you all were talking about the BTRFS file system and
>>> remembered
>>> this article from a few days ago. I build and maintain large SAP
>>> HANA
>>> database servers (physical and virtual) so my only choice is the
>>> XFS file
>>> system which we have been quite happy with.
>>>
>>> Anyway... Interesting read.... :)
>>>
>>> Linux 5.0 File-System Benchmarks: Btrfs vs. EXT4 vs. F2FS vs. XFS
>>>
>>>
>>> https://www.phoronix.com/scan.php?page=article&item=linux-50-filesystems&num
>>> =1
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> https://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
--
Allen Beddingfield
Systems Engineer
Office of Information Technology
The University of Alabama
Office 205-348-2251
allen at ua.edu
More information about the Ale
mailing list