It's very doubtful that Ubuntu's beta status has anything to do with your drive issues.
Your drive is having difficulties, but there's no way to know for sure if the problems are fatal based on your log output. These are the relevant lines indicating trouble:
Mar 31 22:26:06 talk kernel: [13354.939177] end_request: I/O error, dev sdb, sector 488459069
Mar 31 22:26:06 talk kernel: [13354.939344] end_request: I/O error, dev sdb, sector 488459180
If these errors are due to reads, the physical disk sectors may be salvageable by simply overwriting them. Sectors can be written with bad checksums due to power failures. Subsequent reads of these sectors will produce I/O errors because the checksums don't match the data. Overwriting such sectors will fix the checksums and the reading the sector will work again. I've fixed several drives this way.
But it may be that the physical blocks have indeed failed and your drive has run out spare blocks to replace them. In this case, the drive should be scrapped.
What you should do now is buy a replacement drive and copy the data off the drive that's having problems. Once that is done, you can experiment with overwriting the bad sectors and see if the I/O errors go away.
To answer the question i make an assumption:
You are using rsync locally, transferring from a mounted SD-card to backup space
MMC are formatted with FAT-filesystems, so its always useful to set --modify-window=1 because FAT-filesystems store timestamps in a 2 second resolution.
man rsync gives the option --size-only which ignores the last-modified flag of the files. So only files with modified size, e.g. edited ones will be synced.
Another option would be to set the option --modify-window to the time difference between the two timzeones in seconds.
e.g. for 2 hours use modify-window=3660 if there is a 1 hour difference
maybe the is a problem with your UTC setting.
You can check if your hardwareclock is set correct by typing date --utc
Xour softwareclock is given by date.
The value should have the same difference as your local timezone to Greenwich Mean Time.
Your hardwareclock should always be set to UTC so all timestamps are set correct even when you change timezones(softwareclock).
If the UTC time is not correct, check if it ist set correct in your BIOS. If not, correct it.
If it is set you can check /etc/default/rcS. The should be the following line (Ubuntu 12.04)
#assume that the BIOS clock is set to UTC time (recommended)
UTC=yes
Best Answer
Caching is transparent. It does not affect a file's metadata. A file's access date shows when the file was read, never mind whether reading the file caused a read from the disk.
By default, Linux does not update file access times. The default mount option sine kernel 2.6.30 is
relatime, which sacrifices the usefulness of file access times for a small performance gain. It seems that your filesystem is mounted with therelatimeoption, so the second read of the file didn't update its atime.