4 ms·
My systems routinely report transferring files at speeds much faster than what the physical medium asked, only to have them get stuck and fail on a time out a w
by Rygian 3y ago
My systems routinely report transferring files at speeds much faster than what the physical medium asked, only to have them get stuck and fail on a time out a while after.
Having such behavior be the default is, to my limited understanding, a bug in the Linux kernel.
- adr1an 3y agoThere's "$ sync" to ask the Kernel to start the actual write. And "dd" command has the option to do so, too. It's just not the default, as many things on Linux, unfortunately.
- JackSlateur 3y agoYou can see this the other way When I write lots of data to a rusty device and don't sync, the kernel gives back more quickly. From there, I can move on with my work : everything is "as-if" the data were actually copied (except power-cutoff protection, indeed) As such, I see this behavior as a feature, it allows me to wait less and do my work quicker. Unless windows, on which I must wait for the whole data to be written on the disk.
- Rygian 3y ago> As such, I see this behavior as a feature, it allows me to wait less and do my work quicker. So, when (if?) you notice that the transfer has failed with a timeout, do you still consider your work was done quicker?
- JackSlateur 3y agoThere is no timeout possible for IO cache If you are thinking of something like a HTTP download, the transfer has to be done anyway (and I must wait for it). However, I do not need that data to be fully written to the (potentially busy) local device
- Rygian 3y agoMy initial comment was about a simple 'cp' copy of a large file from local storage to an NFS mount. It times out, 'cp' exits in error, and my file is not transferred. I can reproduce this at will. I think I should report it as a linux kernel bug, to be honest.