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

[Alistair Dsouza]

Yes, we are not trying to directly access the data via calls outside the
file system so the VFS should have handled it correctly.

Our logs don't show any type of errors related to SD card access or file
system access in general.

Thanks,
Alistair


On Sat, Apr 23, 2011 at 9:04 AM, Cameron Simpson <cs at zip.com.au> wrote:

> 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.
> --
> Please use reply-all for most replies to avoid omitting the mailing list.
> To unsubscribe or change options:
> https://lists.samba.org/mailman/listinfo/rsync
> Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/rsync/attachments/20110425/9058ad74/attachment.html>