On 07/15/2014 10:44 AM, Paul Robert Marino wrote:
> I have a question about your test did you unmount the stick between
> runs of rsync.

The script automatically does that.  Same behavour this morning
after a power off of the machine last night.  It too about 3 minutes
to catch all the updates I had made.

> if not you may have already had all of the information
> about the filesystem cached in memory instead of having to search the
> FAT table for information. this could have a huge effect on the speed
> of an update.

This is the first time I have observed this behaviour.


>
> also I think it also is in the reformatting the file system may have helped.

I was wondering that too.

> I did a little testing on the st_block vs st_size discussion yesterday
> what I found was interesting.
>
> Older versions of Linux (2.4 kernel, yes I have a few non-networked
> vintage boxes running for specific tasks like operating older robots
> which require special kernel modules) displayed the behavior I
> mentioned about the file size in stat but newer versions of Linux did
> not.
> I also know for a fact MS Windows acts this way because I ran into it
> last year on Windows 2008R2. I hit it when a tool I wrote to do a
> quick check to see if certain tape restores were working properly I
> found it worked perfectly on Linux but in MS Windows It had problems
> because it would return different byte sizes in st_size based on the
> filesystem the file was restored too, but if i copied the file
> afterword to a Linux box I always get the right size.
>
> So at this point its just a theory but its making me wonder if there
> is a difference in the formatting at some low level which doesn't
> break compatiblity but effects the value returned by st_size.
> Microsoft has a history of do strange things to filesystems in the
> name of speeding up writes that in the end hurts them in other ways,
> just consider how often MS Windows boxes need to be defragmented as an
> example.


I support a lot of backups on Windows machine.  Something is
always going wrong.

> further more I have a question about your test did you unmount the
> stick between runs of rsync.

The script automatically does that.

> if not you may have already had all of
> the information about the filesystem cached in memory instead of
> having to search the FAT table for information. this could have a huge
> effect on the speed of an update.

Never helped before.

>
> In any case when I get time I will investigate it more thoroughly.
>