I’m weighing the advantages of formatting a new Linux OS with EXT4 vs Btrfs with ‘noatime’. I learned through forum-lurking here that Btrfs particularly benefits from noatime, as it eliminates performance drains associated with causing disk writes from read-only operations. I have a pretty speced-out machine, though; still, I’m a bit of a performance queen.
I also saw some reason to believe playback latency on Btrfs, while negligible at first, might become unpredictable with greater complexity (e.g., more numerous tracks and effects) – possibly up to 1.5 ms (mind you, according to some retardUD2 AI chatbot).
I’m definitely one to overcomplicate things – hoping the more experienced audiophiles can help me see the forest for the trees here. I doubt the performance loss of Btrfs is going to be that bad; but I’d still like to know what gains and losses I’m hitching my cart to.
PS – I’ve seen a lot of these ultra-granular filesystem performance charts; I don’t think they’re too relevant for single-drive laptop multimedia creation (rather, networking and RAID drive configurations I’m not going to get into). If I wanted to go that far, I’d be on about XFS; but the performance advantages there seem negligible for my purposes.
Basically, none of this is important unless you plan to use very high track counts (where very high likely means more than 60-80. There are people who do this - Jacob Collier regularly uses 300+, but most of his tracks are almost entirely empty.
I usually max out around 40, and normally not even 20. (I’m also looking at video editing, but probably not respectively much more, in terms of project complexity.) Are the ext4 gains just completely negligible in this case?
And you’re where I learned about the noatime tip at Best Linux Filesystem for Ardour in terms of Performance.
It seemed you were referring to any given filesystem type, not just Btrfs. Is that right?
Don’t use compression with btrfs as it makes writing files slower. Btrfs is a very complicated system and some of its features are not finished yet. I prefer XFS which is stable, mature and performs better: https://www.phoronix.com/review/linux-615-filesystems#page-6
You can use btrfs on the OS disk / partition and XFS on the audio / partition - disk, if you want to have both. I recently migrated to Arch - linux and have btrfs on the OS partition with modest compression. It makes booting faster, but sometimes when reading directories the os just halts for 1 - 2 seconds and sometimes not. I use XFS on my audio partition.
How does compressing files on write translate to negative effects? The way it sounds from OG Fedora forum users, disabling CoW negates the bulk (maybe all?) of Btrfs’ safety features. If that’s a true(-enough) statement, it means why use it at all, right?
Now going all in with XFS was the most recent temptation – but the takeaway I all but came to today was, “Most practically, it’s only all that that great for networking, spanning multiple drives, or working with many multiple TBs.” Would you say that’s untrue? I don’t mind taking a few extra minutes rendering/bouncing down heavy FX processing on my single-drive laptop by not using XFS, if that’s all it means.
And I guess one of the main devs for this project is himself saying it hardly matters the way us spec whores think…
My machine has performance metrics to spare. Part of me is willing to shave a little performance for file-integrity features; the other wants to perfect that performance wherever reasonably (ro sometimes unreasonably) possible… but yet another thinks I’m gladder to hear Paul’s takeaway, and just remove self-imposed obstacles to selecting the easier format that fits my desired workflow.
But NOW you’re perking up my gullible performance glutton’s ears again… I’m listening
If you are never going to max out the performance of your computer, then it probably makes no difference which filesystem you choose. Maybe you just need to start with one and get some experiences. Next time you reinstall you may choose another. My experience with btrfs is that with compression sometimes I have filesystem read pauses that I didn’t have with XFS. This is just a minor annoyance and I haven’t reformatted my os drive. Next time I reinstall I will return to all XFS. Btrfs is great if you need to take filesystem snapshots and that was the main feature I chose it for.
Thank you, Mikael, for your time and feedback. All I’m coming from (per semi-pro audio) was using Pro Tools on Windows.
You mentioned the pain point in context of read operations; do you think setting the session workspace to noatime would reduce/remove those pauses? That’s my hope – it would both quell my performance gluttony and justify going with my OS’ defaults.
I also used to be an audio engineer and used Pro Tools at work. That was about 10 years ago
I think updating file access times might add unnecessary wear to SSD cells so I would recommend using the noatime - option. Just checked and I seem to have forgotten to add it to btrfs mount options this time when installing Arch.
I don’t know the cause of these pauses and come to think of it I also recently find out I had buggy firmware on my SSD and upgraded it a couple of days ago. Sorry to add to the confusion 'cause I now realize it’s quite possible the firmware was responsible for the pauses. It’s too early to tell if that was the cause.
+1 for XFS
Been using it for media drives since the SGI IRIX days, doing audio for animations. It’s really well-tested and reliable, with nice recovery tools. In 30-something years, I remember exactly one unrecoverable failure that messed up one Mixbus project, about 10 years ago.
Compression requires CPU cycles and so takes extra time and processing. Both on write and read, although usually the compression algorithms take a little more processing power for writing than reading.
Audio and video do no compress well or at all with standard compression algorithms, so if you are primarily concerned with media performance then it is just wasting CPU cycles for no benefit.
Does it actually degrade A/V files as well ? My instinct is no; Btrfs/CoW uses a lossless compression. You’re saying it’s pointless; not damaging, right?
Correct, it does not change the data, but typically doesn’t save space with media files. You can try something similar by using zip or gzip or similar compression program on an audio file and look at the original and compressed file sizes.
I’m listening