files not moved immediately to final destination from temp location after rsync returns with success

Cameron Simpson cs at zip.com.au
Fri Apr 22 21:34:43 MDT 2011


On 20Apr2011 19:29, Tony Abernethy <tony at servasoftware.com> wrote:
| OK, I'll bite.
| With all file system designs, there is a tradeoff between speed and safety.
| This tradeoff occurs at all levels where there might be something that buffers information.
| Writing into the middle of a structure can be incredibly slow if everything is done safely.
| 
| Enter disk caches (Operating System, Disk controller, Disk itself)
| Much much faster, BUT if mother nature pulls the plug, very weird things can happen.
| 
| Expect everything to be very non-informative about the strategy used.
| 
| With an SD card I would expect everything in the chain to NOT wait for the SD card to be finished.
| Might even take a few minutes for the disk cache to be flushed to the SD card.
| Makes no difference unless you pull the SD card prematurely 
| (or possibly in some cases actually look at what is actually on the card)

And none of this matters.

The view from within the OS should be consistent, regardless of the
state of the disc buffering. Any other behaviour is a bug.

To be explicit, if I went:

  mv huge_file /mnt/the-sd-card

and the mv completes (the command exits), no examination of the sd card _via
the filesystem_ (directory listings etc) will not show the huge_file on
the card and the huge_file gone from its original location. I/O copying
of data to the card may be happening in the background, but the logical
view will be as it it were all complete.

Of course, doing direct access to the card device, _outside the filesystem_,
can should incompleteness. But that's not what the OP is doing AFAIK.

Cheers,
-- 
Cameron Simpson <cs at zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

Some people have all the luck.  When I find the guy with mine, I'm gonna
kick his teeth in.


More information about the rsync mailing list