BTRFS performance in 2020

[mr_raider]

Anyone seen these benches?

https://www.phoronix.com/scan.php?pa...esystems&num=1

https://www.phoronix.com/scan.php?pa...esystems&num=1

The numbers on SSDs and NVME drives make btrfs look pretty bad. Been using btrfs almost exclusively for my production systems since 2015 with no issues really. But I wonder if I'm crippling my performance, in particular my game loading times VM performance, since I run exclusively non rotational media these days.

I'm due for 20.04 re-install this summer, and I'm contemplating going back to good old ext4.

[oshunluvr]

Do you feel like your file system performance is slow? Technical benchmarks rarely reflect real-world use, nor to they take into account other real-world factors like ease of use and features.

My point is, don't make a decision based solely on something so ephemeral as a random benchmark.

[GreyGeek]

Benchmarks are good measures of benchmark software. Real world? Not so much.
I'm running K20.04 on an 8 year old Acer V3-771G with 16GB of RAM and an Nvida GT 650M as the graphic driver of my DE.
My slowest app, Minecraft, takes about 15 seconds to start but after that I get 200-400 fps. LibreOffice starts in under 3 seconds. Most of the applications I run open in under a second.

Those articles don't include the benchmark that means the most to me: backup and restore times. I can open a Konsole, sudo -i to root, mount my root_fs and do a snapshot of @ and @home, umount /mnt and exit twice, in under a minute. EXT4? You're talking tens of minutes to hours, but, those processes can be run in the background while you do other stuff. I just like to know that when I exit out of my root Konsole my snapshots are secure and I can do what ever it is that I wanted to do without the fear that a corruption of my system can mean a loss of my data.

If I do an incremental BTRFS send of @yyyymmdd and @homeyyyymmdd to a remote SSD it will take about 30 seconds for @ and 60-90 seconds for @home, depending on how much has changed. Considering how long it used to take the time savings and ease of use for BTRFS is substantial over tar, rsync and other methods.

EXT4? Don't know. Never tried to find out. IF I were to revert to EXT4 I'd use TimeShift to be sure, but realize that it will be a much slower process to back up and restore. TimeShift uses incremental backing up to make its backups, even on an EXT4 system, but it still takes a long time to make copies of the changed files because EXT4 is not CoW and TimeShift has to analyze the files in the system to see which have been changed. BTRFS does that on the fly with CoW, so a snapshot contains that info already.

And, Ubuntu added ZFS with root file system installation capability. But, I don't have enough EEE RAM to run it reliably and if I did install it I'd delete zsys and zsysctl and rely on the standard zfs commands because Ubuntu's addons produce different snapshot environments and they'd confuse each other.
I've been using BTRFS for 4.5 years and it has been flawless for me.

[oshunluvr]

As for me, I've run through a lot of various file systems looking for performance over the years. As time as moved on, first SSDs and now NVME drives are so fast the lag from one file system to another simply is a non-factor for me. Features far out weigh a microsecond measurement of speed.

Besides, let us never forget - at least we're not using NTFS!

[claydoh]

We are so pampered these days with ssd and nvme prices dropping and speeds increasing.

When I got my new laptop, I purchased a dirt cheap adata su800 as a second drive. I installed it and booted to clonezilla so I could move Windows from the oem nvme drive to the new ssd.

I set it up, ran it, then went to grab a drink. By the time I got back from the kitchen, sat down, gulped a few swigs of Diet Dr Pepper, grabbed the TV remote, the dang thing was done!


That's on a 525 dollar laptop, even.

Sent from my LM-V600 using Tapatalk

[jlittle]

I appreciate this kind of reply that reviews how some procedure is done. I've picked up a lot over the years reading them. In that spirit..

... sudo -i to root ...

:flinch:

mount my root_fs

I prefer to always mount this via /etc/fstab:

LABEL=foo     /mnt/foo      btrfs   defaults,noatime              0   0

or to enable a user mount:

LABEL=foo     /mnt/foo     btrfs   defaults,noatime,noauto,user   0   0

do a snapshot of @ and @home

(With the proviso that snapshots aren't backups for some purposes.) I prefer using sudo btrfs, and I use the file /etc/sudoers.d/btrfs with this line:

john     ALL=(ALL) NOPASSWD:/bin/btrfs*

so that I don't have to type my password for btrfs commands.

[oshunluvr]

I did a very non-scientific test here. i made 4 file of zeros - 50K, 500K, 500M, 5G - and copied them several times using a loop and "time" to see how long it took. The source file system was BTRFS and the targets were BTRFS and EXT4 and I copied both directions: BTRFS <> BTRFS and BTRFS <> EXT4. I only have one EXT4 partition so I didn't so EXT4 <> EXT4.

Except for the largest file, the results were very similar, in fact almost identical: BTRFS was faster with the smallest file, roughly equal on the next 2, and EXT4 was FAR faster on the 5G file by a factor of 10 or so.

This is actually what I would expect. BTRFS is COW (Copy-On-Write) meaning each time a file is copied it is written fresh in whole and then the file being replaced is deleted (not really but that's another discussion). Thus, ANY many-copy test would result in lower performance for BTRFS vs. any file system that over wrote the target as it saved. You're actually comparing apples-to-oranges.COW vs. non-COW isn't a valid test IMO.

If you considered file safety vs. just performance and consider the potential of an interrupted file save operation, and then add in that except for very large files BTRFS keeps up with EXT4, one might conclude BTRFS is far superior to EXT4 or others.

So for me, since by far most files I access and use are far smaller than 500M, I see no loss in real-world performance. I do notice the difference (and did before the test) that moving an ISO or something of that size was time consuming. Since I rarely do that, the benefits of BTRFS far outweigh the occasional delay during a file copy.

This really illustrates a few points:

• No file system does everything well.
• We are free to mix and match file systems based on our usage.
• Benchmarks are just that - marks on the bench - not often reflective of actual use.

[oshunluvr]

We are so pampered these days with ssd and nvme prices dropping and speeds increasing.

When I got my new laptop, I purchased a dirt cheap adata su800 as a second drive. I installed it and booted to clonezilla so I could move Windows from the oem nvme drive to the new ssd.

I set it up, ran it, then went to grab a drink. By the time I got back from the kitchen, sat down, gulped a few swigs of Diet Dr Pepper, grabbed the TV remote, the dang thing was done!


That's on a 525 dollar laptop, even.

Microwave generation: We stand in front of the microwave and yell "HURRY UP!", lol

[mr_raider]

Ok. So let's look at two usage scenarios:

My main rig for gaming. All th stuff in the steam folder and Gog folder are hundreds of gigs. Would be productive to use an ext4 partition for that? I don't care about the data protection here.

My pvr box which records OTA TV streams. Files are routinely 2-6gb. I do need some data protection there since I don't want to loose a season of Flash or Arrow before I watch it. Otoh I chose btrfs for it in case I ever need to throw in an extra drive and expand storage. Should I use xfs?

[oshunluvr]

So here, I use EXT4 for my VMs because it allows me to use dynamically allocated storage without having to set "NOCOW" on every VM drive image. I tend to make and destroy VMs on a regular basis.

I concur with EXT4 the gaming rig - speed may be a factor there, even if it's just loading the game initially. If you nor concerned about backups or snapshots, then go for performance. You should probably tune the EXT4 FS there for that usage.

As far as the PVR, performance is of no consequence IMO, and being able to expand or contract storage and make backups and snapshots is paramount. I have a media server which currently holds about 7TB of various media. About two years ago I needed to remove two aging drives and replace them with a new but much larger drive - both as a safety measure to prevent drive failure but also to increase storage.They were BTRFS RAID1 configuration and had about 1.5TB of data. I also had 2x6TB drives in the same configuration on the same server as a separate file system. The large array held movies and tv shows, videos, etc. while the smaller array held photos, music, documents, etc. So this configuration meant 8TB of storage fully duplicated using RAID1 in two arrays. All the data is segregated into subvolumes by type - movies, tv shows, etc.

Unfortunately, my server only holds 4 drives so all the bays were full. The first step was to free a bay for the new 10TB single drive. I began by converting the 2x2TB drives from RAID1 to "single" drives. This is a simple single BTRFS "balance" instruction. Then, I moved all the files onto one of the 2TB drives with a "device delete" command, leaving one of the 2TB drives empty of data. Once all the data was off and the drive was "deleted" I physically removed it (hot swap bays obviously) and inserted the new 10TB drive on which I made a single full-device BTRFS file system. I then copied all the data from the remaining 2TB drive and the 6TB array to the new drive using BTRFS send|receive on all the subvolumes. This left all my data on the new 10TB drive as a stand alone. I pulled the second 2TB drive and then made new single drive file systems on the two 6TB drives. I then used send:receive to backup all the media subvolumes onto the two separate 6TB file systems.

All of this took several days because I would start a balance or delete device command int he evening and go to bed. I did the send|receive command much the same way using a bash loop to iterate through each subvolume snapshot.

Here's the kicker: I never once stopped using the server, powered it off or even rebooted it. All of this was done live and on-line. I did remount at one point to switch network access from the 6TB drives to the 10TB drive, but I didn't have to, I could have re-done the same process I did to remove the 2TB drives and never even remounted.

So the point if telling this story, is YES I would use BTRFS on any media server like a PVR or NAS. You could add or remove drives while recording a show if you needed to. It's just too easy. XFS will handle large files better faster, no doubt. But watching or recording a video happens at the same speed regardless of file system. Speed is a non-factor in the use-case IMO.

[mr_raider]

I guess for teh gaming rig I could to btrfs for / and ext4 for /home since home has all my heavy media files and games. Problem is I don't like segmenting / and /home because you always end up with inefficient space usage since you never know how much space to allocate where.

[oshunluvr]

I guess for teh gaming rig I could to btrfs for / and ext4 for /home since home has all my heavy media files and games. Problem is I don't like segmenting / and /home because you always end up with inefficient space usage since you never know how much space to allocate where.

Yes, one of the great advantages to BTRFS is subvolumes instead of partitions. Tough call.

[oshunluvr]

You could always go with BTRFS, evaluate the performance for awhile, then swith back to EXT4 if you feel the need.

[mr_raider]

You could always go with BTRFS, evaluate the performance for awhile, then swith back to EXT4 if you feel the need.

So kept my @ and @home subvolumes. I just cleared space on the SSD to create an ext4 partition and moved my Steam games, GOG games, VMs, etc... on to that new partition and symlinked them back.

Once space was cleared @ and @home together only took 85gigs. So kept the btrfs partition at 200gb and gave 700gb to the ext4 partition for media and games. Moved my torrents/downloads folder there too. All that stuff doesn't need redundancy.

Well see how it goes.

BTW gparted has a hell of time resizing btrfs partitions. I did it manually using btrfs filesystem resize.

[oshunluvr]

Yeah, the BTRFS tools work better to grow and shrink volumes.