Ext4 is the only usable file system

>>108336788
yes
>>108336891
>XFS is the only usable file system
ftfy

>>108336788
What? It’s been my goto file system on my server/NAS for my over 10 years, what issue is this?

>>108336975
> XFS
Can’t go wrong with that.

>>108336788
>worsefs

btrfs killed my dad

>>108337022
cheap scam ssds from india have issues with zfs

>>108336788
I haven't encountered any issues with btrfs on my desktop over the years of using it, but I also don't raid.

>>108336788
Yes, but do not use raid5/raid6, and use a reasonably up-to-date kernel and userspace tools (they actually updated them somewhat recently, I think in Linux 5.x era, to use new defaults for mkfs)

>>108336788
why are you blaming your audio issues on an fs? fix your audio shit.

>>108336788
It's actually upstream for one, so at a minimum it will likely be less buggy and actually integrate with vfs.

>>108337353
Not him, but I use btrfs with heavy encryption. Kernel worker processes can hog the cpu and cause freezes and even hanging of the system

>>108337365
>encryption
*compression

>>108337365
i didn't have this shit with pulseaudio, but it started for me with pipewire. i switched to the zen kernel and it went away.

>>108336788
>Bocchi the Filesystem

>>108337365
>encryption
sorry btrfs doesn't cover the usecase of storing cheese pizza

>>108336788
install and use rtkit to automatically give your audio processes the highest priority
use nice levels to reduce the cpu and io priority of heavy tasks.
use zen-kernel which might make a slight difference in responsiveness.
reduce vm.dirty_background_ratio and vm.dirty_ratio so that your system won't try to cache quite as much data at once if you have lots of RAM and slow disks.

>>108337462
rtkit is borked for pipewire at least on nixos you need to set it manually
already on zen, tried rt too
>>108337379
lower lagency by defaujt thats why
>>108337365
this

>>108337109
>worsefs
I got hit with a data-eating kernel oops from the zfs module on Arch recently, that was enough to get me to switch away from ZFS. Also I hate how much you have to manually tune ZFS to the workload and how many of the knobs are global, it's impossible to have mixed loads performing optimally on a single machine.

And then there's this:
https://neurrone.com/posts/openzfs-silent-metaslab-corruption/

>>108337543
and i've had multiple cases of btrfs eating itself. i guess everyone has their own preferences based on experience.

Depends on your needs, but compression, deduplication and corruption detection work well.

>>108336788
seems like a you issue, i don't have any.

I tried to use zfs with a simple mirror setup with 2 drives and it performed like dogshit even with a large record size. btrfs gives me almost full drive speed with the same hardware and there's almost nothing to configure.

>>108338632
>deduplication
This benefits maybe .0001% of data while inducing a hefty penalty in requirements. Not worth it.

>>108337543
the brutal TRVKE is any out-of-tree FS is going to be an uphill battle. I don't know why people believe zfs is special when it can never be properly integrated like XFS was once the copyright issues were resolved.

>>108339159
>This benefits maybe .0001% of data while inducing a hefty penalty in requirements. Not worth it.
Speaking as someone with like 60TB of data on a 45TB btrfs volume, it is absolutely worth it to dedupe data into CoW copies, especially given that the price of HDDs has begun to climb

>>108339599
Post dedup %.

>>108339606
It takes like a week to read every extent and calculate that since I also use compression, ie longer than a scrub. So no, I'm not going to get fresh statistics for you. Deal with it.

File: FeHNnE_wt9LWQvSg_(1).mp4 (3.4 MB, 720x508)

3.4 MB MP4

>>108336891
old, tested and stable. the gentleman choice.

>>108339651
zpool status -D poolname ?

>>108339680
>zpool
What is reading comprehension? I'm using btrfs you retard.

>>108339693
Sorry, I assumed nobody would be insane and masochist enough to actually use btrfs deduplication. Talk about the worst of two bad choices.

>>108339729
In other words, you didn't read my post properly, and now you're trying to hide your embarrassment. Got it.

>>108339665
XFS > ext4

>>108339754
Read >>108339599 again very, very carefully
>on a 45TB btrfs volume

>>108339754
Not him but he did. You are just retarded.
>45TB btrfs volume

Also btrfs isnt that bad as many of you zfs loving fags claim, the shit is fine.

>>108339729
one could say the same about zfs, hating on btrfs for no reason is a dead meme

>>108337543
It's insane how ZFS devs prioritize shit like dRAIDZ-whatever over critical things like this.

>>108339753
Eh. You still can't shrink xfs volumes so it can be kind of annoying. I agree in general only because I trust the xfs devs over the Ext4 fucks, but everything in the kernel is effectively driven by elExt4 dev.

>>108339880
Isn't ZFS made for giant data centers?
Different priorities from home users I guess.

I've been using btrfs for over 12 years. I've only ever seen total data loss on Enterprise Linux 7 (where it was experimental anyway) and had one free space bug that only broke programs that used info from statfs which was fixed with a rebalance.

>>108336788
>audio crackling

most audio crackling problems on linux come from either

power management
https://docs.kernel.org/sound/designs/powersave.html

or wrong sampling rate
- for example, setting 44.1khz when your sound chip only accept 48 kHz

- some chips have multiple native sampling (44.1khz, 48kHz, ...), if you allow the sampling to change on the fly, you may have
crackling/delay every time you start playing audio with a different sampling rate than the previous played audio.

>>108339924
>muh shrinking
Last time I shrinked a volume was roughtly two decades ago when I wanted to try Ubuntu and I needed to shrink a ntfs vol.
I have literally never in my entire life shrinked a volume in Linux.

>all this when you could just use ext4
i dont get it

If any zfs fan here fancies doing some testing, this pool of mine was semi-reliably triggering the metaslab corruption bug with 2.4.1 and Linux 6.18.13 just by repeatedly running KDiskMark on the empty "1M" dataset.

zpool create -o ashift=12 -o failmode=continue -o feature@blake3=enabled -o feature@large_dnode=enabled -o feature@block_cloning=enabled -o feature@dynamic_gang_header=enabled -o feature@edonr=enabled -o feature@embedded_data=enabled -o feature@large_blocks=enabled -o feature@livelist=enabled -o feature@log_spacemap=enabled -o feature@lz4_compress=enabled -o feature@spacemap_histogram=enabled -o feature@spacemap_v2=enabled -o feature@zilsaxattr=enabled -o feature@zstd_compress=enabled -O atime=off -O compression=off -O relatime=off -O checksum=blake3 -O utf8only=on -O devices=off -O direct=standard -O dnodesize=auto -O setuid=off -O logbias=throughput -f -m /mnt/bad bad mirror sdb1 sdc1
zfs create -v -o recordsize=1M -o compression=off bad/1M

ZFS on my servers
btrfs on my desktops

simple as

>>108340004
pipewire defaults to tiny buffers, so its really easy to cause crackling.

>>108340090
I genuinely don't understand what the point of these audio daemons are. They all work like shit compared to writing out an asound.conf that uses dmix.

>>108340047
>Limited inodes
>Zero CoW features, not even reflinks
>Not even the most performant filesystem

>>108340150
In low concurrency scenarios ext4 beats xfs. There are no faster filesystems than those.

>Zero CoW features, not even reflinks
Rarely useful anyway. Also, snapshots are not backups.

>>108340177
>In low concurrency scenarios ext4 beats xfs. There are no faster filesystems than those.
sorry but we are in 2026, concurrency is the norm.
pretty sure f2fs beats ext4 in flash based media. and xfs beats ext4 in everything.

>Rarely useful
just because you dont use it doesnt mean anything

>>108340235
f2fs should not be used on proper SSDs with a translation layer. It should only be used on dumb flash like SD cards or eMMC.
Additionally, that speed comes at a cost of being very wasteful with allocation and alignment.

>>108336788
I’ve never lost a single ZFS pool, including some configurations that are ill-advised like a singleton vdev on a system with non ECC memory.

Every btrfs pool I’ve made has either been lost or rendered read-only. I also never tried to use their raid5/6 garbage, and their “raid10” is a fucking sick joke that bears no resemblance to its namesake.

I’m using Arch Linux with the latest kernel and zfs modules, all features enabled (though not used, obviously), and all my Linux hosts use ZFS on root. Not sure what the hell you guys are doing to corrupt a pool, but I have hundreds of thousands of spindle hours on ZFS without a single issue apart from one corrupted snapshot on the singleton vdev; which was resolvable without a reboot or reimport by simply destroying the snapshots. (Which were of course already replicated to other more durable pools.)

My main system had one half of the mirror dropping out randomly due to a Samsung firmware bug for a few months, and even THAT pool is fine, so I’m pretty confident that whatever you guys are doing with ZFS must be quite retarded.

>>108340290
Enjoy your data loss. Even oracle acknowledged this one, it's not an imaginary issue.

>FAT32
>NTFS
>Btrfs
>ext4
>exFAT
>zfs
>VMFS3-6
>ReFS
>CephFS
Used all of those and never had a single problem. Only unemployed hobbyists and autistic faggots would argue about file systems. Only tinker-troons manage to break filesystems, because they can't help themselves and NEED to tinker with shit that should not be touched.
>pick whatever is default for the OS
>use it
>don't tinker with it like some mentally ill faggot
>profit

>>108340264
>f2fs should not be used on proper SSDs with a translation layer.
You really do not know what you are talking about, do you? f2fs should only be used in flash media WITH a translation layer.

>>108340452
F2FS is dogshit on modern SSDs precisely because of the translation layer. It should only be used on earlier SSDs and dumb flash, and I stand by that.

>>108340478
I don't give a shit about your opinion on f2fs, it is designed to work with a FTL and we are not even talking about f2fs, it was an example to show that ext4 has been surpassed.

Also forgot to mention that ext4 being faster than xfs in low concurrency was a problem that was solved decades ago with "delayed logging" in linux 2.6.x. nowadays is faster in every single way.

>>108340125
> what the point of these audio daemons are
On sun systems can just write μlaw /dev/audio.
We can’t have that, though.

I suspect these audio daemons were (and are) part of a long-term DRM plan, eventually locked to systemd and safeboot/tpm or whatever.

>>108337138
At least it didn't kill your wife.

>>108336788
Probably configured the disk controller to use the same interrupt as the sound card. Or perhaps one of the I/O ranges are overlapping.

But really, most users are going to have off-line backup rotations, and in those cases you might as well be using the original ufs from the 70s and 80s filesystem.

>>108337138
Btrfs touched me in my nono places. We should make a anti-btrfs foundation for the victims of btrfs.

File: Btrfs.png (8 KB, 540x344)

8 KB PNG

>>108336788
>bocchi the rock file system

>>108339924
>can't shrink xfs volumes
That's why you use LVM.

>>108340351
Pretty much. I did experience exFAT corrupting the entire volume with a single write error, but even that is apparently by design. Can't recall any issues with any fs otherwise. I like ZFS.

>>108339425
sounds more like a case of new kernel branch + new fs release, rather than anything to do with it being out of tree. ZFS on RHEL is stable, due to staying on the mature branch by default and because of the frankenkernel.

the lack of integration is a bit sad, but ZFS itself is robust and featureful enough to make up for that, imo.

>>108336788
>better
No, but it'll use less RAM.
>audio crackling
changing filesystem isn't going to fix a noise issue. Get an Applel USB-C to 3.5mm, problem solved with best value DAC on the market.

>>108344473
you are a moron

>>108340125
dmix is an audio daemon...
>>108340893
If you use OSS instead of ALSA you can just pipe pcm to /dev/dsp
ALSA can't do it, it's aids.

>>108344500
dmix is not an audio daemon, it's a plugin. And it uses shared memory to do its thing.

>>108339729
btrfs deduplication is far easier and less painful than zfs, all you have to do is run duperemove, you can even do it on whatever data that would benefit instead of running it online on the entire pool at all times (with the massive ram cost this can bring)

>>108344937
duperemove doesn't work with compressed extents
You have to use beesd for that

still unconvinced we need anything more than ext4
only dumb arguments I've heard are
>corruption
>bitrot
which only affects 3rd worlders who worry about blackouts
any real arguments for btrfs?

>>108336788
>audio crackling while moving file

AMD?

>>108344937
what's the point? just use compression

>>108346494
y but i have external interface

>>108345898
"bitrot" has nothing to do with blackouts, it's long term or accidental data loss due to unavoidable hardware deficiencies. btrfs and zfs can self-heal data on any redundant array, to get the same effect on ext4 or other filesystems you'd need to stack it on top of md raid on top of dm-integrity volumes (md responds to the error code indicating a data checksum failure from dm-integrity by fetching from a different raid device and it should also correct the bad block), but the whole thing is a slow, proverbial house of cards. There's also the issue with dm-integrity potentially losing an entire volume if vital blocks are corrupted, it was designed for use with crypto and data *resilience* was never a goal.

>>108347361
USB is even worse.

File: 1770034479026904.jpg (5 KB, 250x250)

5 KB JPG

>>108336975
>can't be resized

>>108347824
It can be resized, are you okay anon??
Maybe you are poor and you are talking about shrinking, in that case I'm sorry for you.

>>108344559
So? are you aware that explaining how something works does not prove (or disprove) anything and that nobody gives a shit?

File: file.png (206 KB, 499x444)

206 KB PNG

>>108336788
I use both on my kubuntu 22.04 box and they just work, even with the shitty samsung QVO drives serving 2 vms that run the entire time the desktop is on

>>108348943
Don't know if you noticed but you put the "swap" subvolume inside the "@" subvolume.

File: file.png (52 KB, 569x96)

52 KB PNG

>>108349110
yeah I don't remember how it got created but I haven't bothered to fix it since it doesn't actually get used. I have a separate partition on the drive marked nocow to get hibernation to work

>>108347824
One reason more to use LVM volumes for all your stuff.

>arch + luks + ext4 + lvm + pipewire + xlibre + xfce4
you don't need more

>>108336891
This. When in doubt, Chudmaxx.
Theodore Tso hates CoC and Rust.
Honorable mention to ReiserFS.

only thing i don't like about ZFS is how it will automount and merge shit to the same mountpoints and fuck my shit up

>>108349411
don't need LUKS, LVM or GPT when you have ZFS.

>>108350058
those things are in the kernel, zfs is not in the kernel

>>108350079
you're mom is in the kernel

>>108350105
She's not in the kernel but she uses the kernel.

>>108350119
linus is a colonel and he uses she

>>108350016
>how it will automount
Turn it off? Skill issue.

>merge shit to the same mountpoints
That's just Linux allowing mountpoints to overlap. Any fs can be mounted over any directory, no matter where it is.

>>108350245
yes, it's a skill issue. the more ZFS fucks me in the ass the less it hurts.

>>108350245
ok genius, so how do i prevent my system merging root and home after inserting a disk containing a boot environment that just so happens to automount? how would you "turn it off?" at that point? you can't export the pool because the system is using it.

>>108350341
zfs set mountpoint=legacy $pool and then manage it manually the same way as every other filesystem?

>zfs
lulwut

so ZFS is unreliable now?