Use fdatasync() when copying/moving files to calculate their proper transfer speed

[birdie]

In Linux the dirty write cache buffer makes MC's speed calculation incorrect - the file might not have been written out to the storage, yet MC will calculate its transfer speed regardless.

Please, use fdatasync() for every 64MB (it's you to decide, or maybe it's worth making this variable user configurable) of transferred data.

More on this problem: ​http://lwn.net/Articles/572911/

​http://linux-kernel.2935.n7.nabble.com/Disabling-in-memory-write-cache-for-x86-64-in-Linux-II-td742553.html
or
​http://comments.gmane.org/gmane.linux.kernel.mm/108708

[eugenesan]

Note: fdatasync does not exists in OSX but mistakenly detected by configure.

[gotar]

One might say that current speed calculation is correct - it shows when mc would finish copying and user could get back to work.
I don't want to wait for 64 MB to be written while copying 65 MB file to the USB stick - I expect mc to return from the dialog ASAP and let the kernel do the rest of the job.

[birdie]

Replying to gotar:

One might say that current speed calculation is correct - it shows when mc would finish copying and user could get back to work.

Speed calculation? In this case?! More like there's no speed calculation at all - according to your own words. You only want to know something has been cached, not even written out for further use.

I don't want to wait for 64 MB to be written while copying 65 MB file to the USB stick - I expect mc to return from the dialog ASAP and let the kernel do the rest of the job.

So, you don't care about 1) data safety 2) real data transfer speed.

I fail to understand why you even commented on this bug report. It's meaningless for you.

[egmont]

I fully agree with gotar.

The kernel knows what's the best wrt. caching, being aware of what other applications are doing at the moment, etc. Calling fdatasync() might actually slow down the operation, and would definitely delay the moment the user gets back the control in MC and might continue the work (e.g. start copying other files). If, let's say, you copy files one-by-one, your overall speed would significantly drop by fdatasyncing. An approximate reporting of transfer speed is good as long as it doesn't slow down your actual workflow. Making it more accurate and slowing down your work at the same time is a bad idea.

Data safety: You need to safely eject the USB stick, it'll take care of it. It's the same with any other utility that writes to the pendrive. It should be the "eject" operation (once per device removal) that blocks the user's workflow until the kernel actually completes its work, not the "copy" operation (once per copying with F5). What you're asking for is not safety but paranoia.

[ossi]

fwiw, using sync_file_range(SYNC_FILE_RANGE_WRITE) rather than fdatasync() might actually make sense. that's linux-only, but as an optional feature that's fine.