@robyn Switching to Linux is a bit of a gateway drug. You start for the privacy, but you stay for the freedom. It’s addictive in the best way possible—once you realise you actually own your computer again, there’s no going back.

#Linux #FOSS #Privacy #Tech #OpenSource #SwitchToLinux

@agowa338 It definitely feels like a race condition, but it's likely just the kernel merging new writes into the active transaction to keep the RAID 5 parity consistent. It won't close the "flush" until the dependencies are clear, which is why it keeps moving the goalposts.

It’s a frustrating quirk of the Linux I/O stack on slow arrays. Good luck getting the rest of that data moved—hope the HDDs hold up!

@agowa338 20 is definitely the sane default for most workloads. Setting it to 0 just proves the cache was the "jam" in the first place.

The "stop the world" behaviour is frustrating, but on RAID 5, the kernel is likely refusing to close the current transaction until the parity is consistent. If new data keeps coming, it just keeps the transaction open. It’s a data integrity safety net that feels like a deadlock.

@agowa338 Setting dirty_ratio=0 is the nuclear option. Now your rsync will crawl because it has to wait for the HDDs on every single write, but sync will return instantly because there's no cache left to flush.

It’s counter-intuitive because the kernel is basically "stopping the world" to make sure your RAID 5 parity is actually on the platters. You've basically turned off the "speed" of Linux caching to get an honest sync command.

@agowa338 Since it's dm-raid5, you're hitting Kernel Writeback Throttling.

 sync doesn't just snapshot; it calls fsync on the entire block device. Because  rsync  is flooding the queue, the kernel won't return the  sync  call until the "Dirty" pages hit a safe threshold. On slow HDDs, that threshold is effectively zero because the parity calculation can't keep up with the stream.

It’s not a deadlock, just a very long "stop-the-world" flush. Try  sysctl vm.dirty_ratio  to see your current limit

@agowa338 That confirms it. You're seeing "Synchronous Writeback."

On Btrfs RAID 5,  sync  doesn't just snapshot; it forces the entire filesystem into a consistent state. Because of the RAID 5 parity and LUKS overhead, the kernel is effectively "locking" the  sync  command until the Writeback hits zero to ensure data integrity.

It's a hardware bottleneck disguised as a software deadlock. Your HDDs are the limit.

@agowa338 It's a Btrfs Transaction Lock.

Because of CoW,  sync  triggers a "Transaction Commit." On RAID 5, this can't finish until metadata/parity are consistent. If  rsync  keeps pouring in data, it prevents the transaction from closing, deadlocking  sync  until the stream pauses.

Try  sudo pkill -STOP rsync . If  sync  returns instantly, that's your proof.