Gradual performance decrease copying large file to compressed volume.

[crzsotona]

Prerequisites: Windows 10.0.18363.1256 btrfs driver 1.7.5

Reproduction:

1. Take large file (e.g. OS disk image)
2. Enable compression on target volume (LZO in my example)
3. Copy prepared file to target volume

Here's speed comparison NTFS vs btrfs (compression on in both cases)

Let me know if any additional data is required for investigation.

[TheMadHau5]

I have a small question; why not Zstandard? It's significantly faster than LZO and is similar in speed and ratio to LZX (what NTFS uses). I'd suggest trying that and seeing if it helps.

[maharmstone]

@crzsotona - thanks, I'll try to reproduce. It looks perhaps the same issue as https://github.com/maharmstone/btrfs/issues/58. There's an interesting comment from BlueAmulet at the end, suggesting it's something to do with disk caches.

[crzsotona]

I have a small question; why not Zstandard? It's significantly faster than LZO and is similar in speed and ratio to LZX (what NTFS uses). I'd suggest trying that and seeing if it helps.

It performs the same, no difference on the long run.

[lss4]

Actually I found myself getting into similar issues with 1.7.7. I'm using Windows 7 in this case and the partitions have zstd compression enabled (to match the mount options in Manjaro which I dual boot on the PC in question). After some intense workload (like copying at least 20GB of files at once), the particular partition would eventually stop responding to anything, which in turn hangs the Windows Explorer.

This can happen during and outside file copying, as if the driver can only reliably process that many gigabytes of data and instabilities can occur after that. It's not 100% reproducible as in some cases, I can actually finish copying everything after a system reboot.

When the hang happens it's no longer possible to reboot normally as Windows Explorer can't be killed by any normal means (sadly, Windows doesn't seem to have the kill -9 "nuclear" option like Linux).

Fortunately, this doesn't seem to have caused any serious damage to the filesystem infrastructure, as I can still mount the partition in question under Windows (and Linux) r/w without major issues after restart, and most existing files remain intact. Still, this issue is indeed problematic and poses danger to the data involved.

The partitions were originally created from Linux (as I always manage partitions from Linux nowadays), but it seems there can be some differences between a Btrfs created from Linux and a Btrfs created from Windows.

EDIT: I don't know how Btrfs conversion is now, but a few years ago (around 2016) I found it to be unstable and that was on Linux. I once converted my Arch Linux partitions to Btrfs (from ext4) only to find it being completely broken. The partitions become forced read-only after a few ops and after several fscks the issue was still there that I ended up having to restore a backup. Newly-created Btrfs partitions, however, do not suffer from such issues. As such, a Btrfs partition converted from another filesystem may also have to be treated differently when diagnosing issues.

[Artofeel]

I have the same compression performance loss when compressing large files (>10GB) tried to copy a 60GB file with ZSTD level 2 compression at the beginning the speed was 150MB\sec, after 10GB is copied, it starts to slowly decrease and after 20-25GB it was 10-15MB\sec so I formatted the volume with 64k sector size /sectorsize:65536 /nodesize:65536 and it speeds things up 200MB\sec at the beginig and after 40-50GB it was 30-40MB\sec speed still drops, but at least it usable somehow

It's only happens on Windows driver? Linux is OK?