After the move dialog is closed, can I be 100% sure that the data was completely transferred? i.e: no need to issue sync command?
We recently discussed this:
tl; dr: I believe that only unmounting the device will trigger a
sync and you’ll get notified as soon as the device is ready to be unplugged.
The solution I’ve ended up using after doing searching on the issue was to set the
vm.dirty_background_bytes values so it causes the write cache to be flushed much quicker. I use the settings of 32 MiB for
vm.dirty_bytes and 16MiB for
You can change these values at runtime by using
sysctl in a terminal (you may need to run
sudo depending on the user you’re using):
sysctl vm.dirty_bytes=33554432 sysctl vm.dirty_background_bytes=16777216
Setting the values low can affect IO bandwidth (mentioned in this LWN article), and if you’re using
btrfs then it can’t be too low or it will reduce performance.
You can also create a config file in the
/etc/sysctl.d/ directory, and name it something like
10-vm-settings.conf, then add the
vm.dirty_bytes = 33554432 vm.dirty_background_bytes = 16777216
If you’re using
btrfs then based on a Pop!_OS change, values of 256 MiB and 128 MiB for the respective parameters may be better.
vm.dirty_bytes = 268435456 vm.dirty_background_bytes = 134217728
Linux kernel has a cache of data to be flushed to disks (dirty pages), and write operations done by apps are marked as done as soon as the output data has been written there.
In the general case this allows the kernel to optimize the write to disk operation, and on performant filesystems the delay is hard to notice.
This is not the case when the disk is slow (USB stick…).
We don’t have a way from the app to know if the data has been synced. We haven’t found a satisfying workaround. Calling
sync is pretty bad for instance, as it blocks the thread.
Linux 6.5 cachestat syscall might help, will need to explore this after next glibc release.