mtime vs ctime

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

mtime vs ctime

Andrej
Hi,

We use an rsync (rrsync, to be precise) based back-up solution. Every
so often an
iSCSI based file-system gets brought up and left connected for the
night. After a
mount event rsync will back that volume up, including server TB of
data that haven't
been modified, but the ctime is newer than the mtime.  Is there a way
to stop this
behaviour?


Cheers,
Andrej

--
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
Reply | Threaded
Open this post in threaded view
|

Re: mtime vs ctime

Kevin Korb
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The ctime will always be newer or the same as the mtime.  This is
because changing the mtime also changes the ctime as does other things
like changing the permissions.

Rsync only pays attention to the mtime because rsync can set a
specific mtime (--times) but setting a specific ctime is impossible as
it would violate the basic *nix security model.  Therefore ctime can't
be copied, therefore ctime can't ever be expected to match, therefore
it is useless to rsync.

Rsync should be using the delta transfer algorithm (unless
- --whole-file) so it really should just be determining what is
different about the file then transferring those differences.  --stats
would help determine this.

On 09/07/2015 09:46 PM, Andrej wrote:

> Hi,
>
> We use an rsync (rrsync, to be precise) based back-up solution.
> Every so often an iSCSI based file-system gets brought up and left
> connected for the night. After a mount event rsync will back that
> volume up, including server TB of data that haven't been modified,
> but the ctime is newer than the mtime.  Is there a way to stop
> this behaviour?
>
>
> Cheers, Andrej
>

- --
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
- -*~
        Kevin Korb Phone:    (407) 252-6853
        Systems Administrator Internet:
        FutureQuest, Inc. [hidden email]  (work)
        Orlando, Florida [hidden email] (personal)
        Web page: http://www.sanitarium.net/
        PGP public key available on web site.
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
- -*~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlXuQHAACgkQVKC1jlbQAQeqJwCg7E7HD15wUcJwvZsvrsSXSoNn
2YgAoKs5htAjdk1JUL7rYzI7QxwUOik/
=EHps
-----END PGP SIGNATURE-----

--
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
Reply | Threaded
Open this post in threaded view
|

Re: mtime vs ctime

Andrej
On 8 September 2015 at 13:57, Kevin Korb <[hidden email]> wrote:
Hi Kevin.


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> The ctime will always be newer or the same as the mtime.  This is
> because changing the mtime also changes the ctime as does other things
> like changing the permissions.
>
> Rsync only pays attention to the mtime because rsync can set a
> specific mtime (--times) but setting a specific ctime is impossible as
> it would violate the basic *nix security model.  Therefore ctime can't
> be copied, therefore ctime can't ever be expected to match, therefore
> it is useless to rsync.

If this is the case I don't understand the behaviour I'm
seeing here.  The files mtime haven't changed, the
time-stamps of the copies on the backup server and
the time-stamp on the iSCSI mount are the same (the
mtime, that is; the ctimes differ, obviously, as all files
have the time-stamp of the mount-event).

Do you have an explanation?


> Rsync should be using the delta transfer algorithm (unless
> - --whole-file) so it really should just be determining what is
> different about the file then transferring those differences.  --stats
> would help determine this.

Hmmmm ...

Doesn't look like it to me.

--
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
Reply | Threaded
Open this post in threaded view
|

Re: mtime vs ctime

Kevin Korb
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I would need to see both your existing rsync command line and the
output of --itemize-changes when such an occurrence happens before I
can really understand what is happening.

In the end, if you have any output at all the bare minimum should be
- --itemize-changes.  --verbose is utterly useless without it.

On 09/07/2015 11:10 PM, Andrej wrote:

> On 8 September 2015 at 13:57, Kevin Korb <[hidden email]>
> wrote: Hi Kevin.
>
>
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>
>> The ctime will always be newer or the same as the mtime.  This
>> is because changing the mtime also changes the ctime as does
>> other things like changing the permissions.
>>
>> Rsync only pays attention to the mtime because rsync can set a
>> specific mtime (--times) but setting a specific ctime is
>> impossible as it would violate the basic *nix security model.
>> Therefore ctime can't be copied, therefore ctime can't ever be
>> expected to match, therefore it is useless to rsync.
>
> If this is the case I don't understand the behaviour I'm seeing
> here.  The files mtime haven't changed, the time-stamps of the
> copies on the backup server and the time-stamp on the iSCSI mount
> are the same (the mtime, that is; the ctimes differ, obviously, as
> all files have the time-stamp of the mount-event).
>
> Do you have an explanation?
>
>
>> Rsync should be using the delta transfer algorithm (unless -
>> --whole-file) so it really should just be determining what is
>> different about the file then transferring those differences.
>> --stats would help determine this.
>
> Hmmmm ...
>
> Doesn't look like it to me.
>

- --
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
- -*~
        Kevin Korb Phone:    (407) 252-6853
        Systems Administrator Internet:
        FutureQuest, Inc. [hidden email]  (work)
        Orlando, Florida [hidden email] (personal)
        Web page: http://www.sanitarium.net/
        PGP public key available on web site.
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,
- -*~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlXuVCsACgkQVKC1jlbQAQfYPwCcDNClv4gPHI/jdoQVXZO+Suao
AwgAnAsnCJurds9A37e22Y6ccuMjOq5l
=w8IH
-----END PGP SIGNATURE-----

--
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
Reply | Threaded
Open this post in threaded view
|

Re: mtime vs ctime

Andrej
On 8 September 2015 at 15:21, Kevin Korb <[hidden email]> wrote:

> I would need to see both your existing rsync command line and the
> output of --itemize-changes when such an occurrence happens before I
> can really understand what is happening.
>
> In the end, if you have any output at all the bare minimum should be
> - --itemize-changes.  --verbose is utterly useless without it.


Thanks again, Kevin, I'll have a look at the python wrapper script (it predates
me by about 1.5 years).




--
Please don't top post, and don't use HTML e-Mail :}  Make your quotes concise.

http://www.georgedillon.com/web/html_email_is_evil.shtml
http://www.catb.org/jargon/html/email-style.html

--
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