Wine Reflink Support Continues To Be Worked On For Significant Space Savings

[S.Pam]

So they are overcomplicating it for no reason at all as I see it. You have shared dll's folder, all symlinks point towards that, if dll's are different (by override, hash, whatever), store it locally = problem solved, it always reads local prefix anyway, so why bother, symli9nk would simply mimic the actual file, file would replace it if needed.
In that way, you save space, and if required for different version of the file, add to the prefix, so prefix could grow, but usually it wouldn't, and even if it grows, it would be only for those overrides.
There's probably something I'm missing here, but, that looks like the best solution without overcomplication.

On the contrary. Reflinks are easy, need no complicated rules to manage and are transparent to any application.

cp --reflink /foo /bar

[Etherman]

A lot of workstations also use XFS, which is considered extremely stable.

XFS breaks 32 bit games.

[partcyborg]

XFS breaks 32 bit games.

False. 32bit binaries compiled without -D_FILE_OFFSET_BITS=64 can be unable to stat or readdir on large 64bit filesystems, but this is absolutely not an issue with an open source project like wine

[partcyborg]

Several distros and system use Btrfs these days. It is considered mature and stable. The world is full of anectotal evidence to the contrary for any filesystem, but that in itself doesn't make them risky filesystems.

literally every single time i have decided to give btrfs a try it has ended in an unrecoverably corrupted filesystem. This has happened with both single disk and simple stripe/mirror setups. ill never trust data to it ever again.

Not to mention how god awful slow it is when its not actively eating your data.

From my understanding, one of the original motivations behind the bcachefs project was the abysmal state of the btrfs project and it's failure to provide a stable "modern" open source filesystem

[Etherman]

False. 32bit binaries compiled without -D_FILE_OFFSET_BITS=64 can be unable to stat or readdir on large 64bit filesystems, but this is absolutely not an issue with an open source project like wine

You know there are closed source 32 bit games on Steam, do you?
You don't put your Steam directory on XFS if you want maximum compatibility.

[Britoid]

You know there are closed source 32 bit games on Steam, do you?
You don't put your Steam directory on XFS if you want maximum compatibility.

Iirc you can mount XFS with 32bit inodes now which should resolve the issue.

[Leprechaunius]

I've been considering a switch to btrfs for some time. Are there any noticeable performance differences between btrfs and ext4?

[darkbasic]

There is one problem with btrfs reflinks: if you have two subvolumes independently mounted you won't be able to reflink between them. This is especially annoying when you have snapper snapshots and you try to reflink from a snapshot onto your rw subvolume. Instead, if you mount your root btrfs volume containing all of your subvolumes inside, from there you can reflink between subvolumes. This looks like an easy thing to fix to me, I'm wondering why nobody still patched it up

[Nocifer]

If ext4 doesn't have support, how much use is this actually going to bring? Afaik, damn near everyone (debian/ubuntu most notably) is still on ext4 unless you're a fedora/arch user and like to live dangerously (btrfs).

The Steam Deck will be using btrfs, so there you have it. Also, damn near everyone is still on ext4 due mostly to familiarity/momentum (ext4 has been the default for ages) and benign ignorance (many people think that btrfs is generally unstable because of that RAID 5/6 write hole whatsamacallit they've heard other people talking about); still, most all Linux distros (including Debian and Ubuntu) have full support for it. There is nothing dangerous or experimental about using btrfs (unless you try to use RAID 5/6, and even then failure isn't guaranteed, it's just more possible and more possibly devastating than can be considered as production-safe), on the contrary there are many things about it that put most other filesystems to shame.

literally every single time i have decided to give btrfs a try it has ended in an unrecoverably corrupted filesystem. This has happened with both single disk and simple stripe/mirror setups. ill never trust data to it ever again.

Not to mention how god awful slow it is when its not actively eating your data.

From my understanding, one of the original motivations behind the bcachefs project was the abysmal state of the btrfs project and it's failure to provide a stable "modern" open source filesystem

Care to elaborate a little on that? Because honestly, it just sounds like uneducated trolling.

There is one problem with btrfs reflinks: if you have two subvolumes independently mounted you won't be able to reflink between them. This is especially annoying when you have snapper snapshots and you try to reflink from a snapshot onto your rw subvolume. Instead, if you mount your root btrfs volume containing all of your subvolumes inside, from there you can reflink between subvolumes. This looks like an easy thing to fix to me, I'm wondering why nobody still patched it up

Subvolumes in btrfs are like partitions in other filesystems, in that they are (treated as) separate block devices with their own inode lists. This means that by design you can't have reflinks between subvolumes, in the same way that you can't have hardlinks between partitions.

In truth though the subvolumes are normal directories; it's only when they are mounted as subvolumes that they (think they) are separate partitions. So when you mount the overlying root volume, I'd guess the reason you can reflink between them is because the root volume maintains its own inode table (i.e. file & directory list), so from its point of view the reflink is not between two subvolumes but between two normal directories.

The real question would be: what happens if you dismount the root volume and mount just these two directories as subvolumes? Does the reflink you created persist? Does the second subvolume have access to the original data on the first subvolume? I'd think not, because that reflink probably belongs to the root volume, not any of the subvolumes. But I'm only guessing here, so perhaps someone more knowledgeable could educate us further.

[NobodyXu]

literally every single time i have decided to give btrfs a try it has ended in an unrecoverably corrupted filesystem. This has happened with both single disk and simple stripe/mirror setups. ill never trust data to it ever again.

Not to mention how god awful slow it is when its not actively eating your data.

From my understanding, one of the original motivations behind the bcachefs project was the abysmal state of the btrfs project and it's failure to provide a stable "modern" open source filesystem

Honestly, it takes years for filesystem to mature, especially for a filesystem like bcachefs who is still quite young.

When bcachefs becomes stable enough to use, it is likely Btrfs has been stable enough with majority of its bug fixed for years.