[System] Zero Byte Files

[tenplus1]

I've noticed over the years that quite a few users who copy files from their pc onto external devices are reporting the files as either corrupt or zero bytes in size, and we know that the file-copy buffer still holds much of the file to be copied even after it says that it's completed, which they dont see as they eject their external device.

For the sake of sanity and new users everywhere, wouldnt it be better to add a /etc/sysctl.d/8-writing_buffer.conf file and add the following lines to at least report accurate copy status:-

vm.dirty_bytes=52428800
vm.dirty_background_bytes=26214400

[die.boer]

I've noticed over the years that quite a few users who copy files from their pc onto external devices are reporting the files as either corrupt or zero bytes in size, and we know that the file-copy buffer still holds much of the file to be copied even after it says that it's completed, which they dont see as they eject their external device.

For the sake of sanity and new users everywhere, wouldnt it be better to add a /etc/sysctl.d/8-writing_buffer.conf file and add the following lines to at least report accurate copy status:-

vm.dirty_bytes=52428800
vm.dirty_background_bytes=26214400

"Your proposal is technically sound and would reduce the number of "I copied files to my USB stick and now they're gone" reports. The trade-off is that it slows write-heavy workloads across the entire system, including internal SSDs and HDDs that don't need this behavior.

A more targeted fix would be in desktop software (such as file managers and device management) rather than changing global kernel writeback policy. That addresses the user experience without sacrificing performance for every write operation."

[oshunluvr]

Alternately, teaching users patience and an understanding of how this works might be beneficial. I suspect that attempting an unmount action prior to physically pulling a USB device from the connection would solve 99% of the cases. But humans, so....

[tenplus1]

I have been using the above change in all my systems with a mix of nvme and ssd and have never noticed any slowdown in performance.. And yes, patience is a nice thing to have, but this really is an issue where users cannot see the accurate status of a file-transfer.

[die.boer]

A 50 MiB dirty limit isn't extremely small by today's standards. On a modern NVMe SSD capable of several GB/s, the storage can usually keep up with the application's writes, so the dirty cache rarely fills. In that case, the kernel almost never has to throttle the application, which explains why you haven't noticed a performance penalty.

Where the difference becomes more apparent is in workloads like:
Writing many gigabytes continuously to a slow HDD.
Writing to network filesystems (NFS/SMB).
Backup jobs.
Database or virtualization workloads.

Those are the kinds of scenarios the kernel defaults are designed to optimize.