Nemo reporting false file transfer progress for USBs

[SpeeQz1]

Distribution

Mint 22.2

Package version

nemo 6.4.5

Frequency

Always

Bug description

When copying very large files likes ISOs to a USB progress may not be properly reported depending on the user's available RAM.

Usually one fix is to change the dirty_bytes values:

echo $((32*1024*1024)) >/proc/sys/vm/dirty_background_bytes  
echo $((1024*1024*1024)) >/proc/sys/vm/dirty_bytes

It would be good if nemo handles this visually properly.

Steps to reproduce

1. Get a big enough USB to hold a large .iso file.
2. Open nemo.
3. Copy your .iso file from your computer to the USB.
4. Observe copying progress.

Expected behavior

Nemo reports progress properly.

Additional information

Reference discussions from here: https://askubuntu.com/questions/1117832/copying-files-from-pc-to-pendrive-gets-stuck-at-the-end-on-ubuntu-16-04

[AttilaLL]

#2172 (comment)

[Jeremy7701]

The only reason for transferring ISO's to slow USB devices, is to make them bootable.
Mint supplies the Mint USB stick formatter & the Mint USB Image Writer.

[a-j-bauer]

@Jeremy7701
This happens for all big files e.g. llama files "pretrainedmodel.gguf" which are > 2 GB.
The OP was using .iso as an example.

[velnari-malakh]

Reproduced on Linux Mint 22.2 with Cinnamon 6.4.8, Nemo 6.4.5, GVfs 1.54.4, UDisks 2.10.1 and kernel 6.17.0-35-generic.

Source was a fast internal NVMe SSD. Destination was a USB 3 flash drive connected at SuperSpeed. The test file was a 49,094,128-byte ZIP copied through Nemo.

With the normal UDisks FAT mount options (flush, without sync), the destination reached its final logical size and Nemo’s transfer window disappeared, but monitoring /sys/block/sdX/stat showed physical device writes continuing for approximately another 10 seconds.

The source and destination SHA-256 hashes matched after writeback completed. The immediate problem is therefore misleading completion reporting: Nemo reports that the operation is finished when data may still only be in the Linux page cache. A user can reasonably interpret the closed window as meaning the USB transfer is complete.

As a diagnostic A/B test, I configured UDisks to mount removable filesystems with sync. After remounting, Nemo’s progress followed the real device writes and no hidden write activity remained after the window closed. However, transfers became dramatically slower, so this is not a good general product-level workaround.

Expected behaviour: Nemo should keep the operation visible—possibly as “Finishing writes to device”—until the destination data has actually been synchronized. The completion state should only appear afterward. Busy and safe-to-remove notifications should also be visually unambiguous.

PR #3726 appears to improve page-cache throttling by starting writeback every 32 MiB. However, its successful completion path calls sync_file_range(..., SYNC_FILE_RANGE_WRITE) without a final wait or fdatasync()-equivalent operation. This may leave the final chunk outstanding when Nemo reports success. Files smaller than 32 MiB also appear not to enter the throttling path. Testing files in the 10–64 MiB range would therefore be valuable.

This matters particularly for ordinary users performing backups: the current interface can make them believe a removable-device copy has completed before the device has finished writing.

[Jeremy7701]

When the USB is un-mounted, prior to physical disconnection, any outstanding data writes will be automatically flushed.