ZFS and ctime
Lucien Pullen
<https://groups.google.com/group/zfs-macos/browse_thread/thread/37930f1dbe97c18a>
and some other posts about using git with ZFS.
I ran some simple tests, and it appears that ZFS is setting the ctime
_AND_ atime of files when they are accessed using certain tools. You
can `stat` a file all day and won't see a change, but running
something like `git diff` on it will bump both the ctime and
atime. Obviously, with core.trustctime turned on in git, the ctime
will always be different whenever you run anything that does a diff,
which will cause git to fail happily.
I'll have to look at the source and ZFS On-Disk Format PDF again to
see what the inode looks like, and I will see what a Solaris ZFS does
in this situation. I'm thinking there might be a bug in the maczfs
implementation because I was using Nexenta as my server and ran into
no such problem (was using git to sync website).
Alex Blewitt
> This is in relation to
> <https://groups.google.com/group/zfs-macos/browse_thread/thread/37930f1dbe97c18a>
> and some other posts about using git with ZFS.
>
> I ran some simple tests, and it appears that ZFS is setting the ctime
> _AND_ atime of files when they are accessed using certain tools. You
> can `stat` a file all day and won't see a change, but running
> something like `git diff` on it will bump both the ctime and
> atime. Obviously, with core.trustctime turned on in git, the ctime
> will always be different whenever you run anything that does a diff,
> which will cause git to fail happily.
I think it's a resolution issue rather than modifying the creation time all the time. Because they're different, Git thinks they're different and so notes the change - but it's easily fixable by setting the trustctime off, as you noted.
Alex
Lucien Pullen
> On 10 Feb 2012, at 21:09, Lucien Pullen wrote:
>> I ran some simple tests, and it appears that ZFS is setting the ctime
>> _AND_ atime of files when they are accessed using certain tools. You
>> can `stat` a file all day and won't see a change, but running
>> something like `git diff` on it will bump both the ctime and
>> atime. Obviously, with core.trustctime turned on in git, the ctime
>> will always be different whenever you run anything that does a diff,
>> which will cause git to fail happily.
>
> I think it's a resolution issue rather than modifying the creation
> time all the time.
Then how does that affect the output I'm seeing? Example:
% stat Undirected.cs
File: "Undirected.cs"
Size: 34897 FileType: Regular File
Mode: (0644/-rw-r--r--) Uid: ( 501/ lucien) Gid: ( 20/ staff)
Device: 44,21 Inode: 3104 Links: 1
Access: Fri Feb 10 17:14:16 2012
Modify: Thu Feb 9 17:38:18 2012
Change: Fri Feb 10 17:14:16 2012
% git diff -- Undirected.cs
% stat Undirected.cs
File: "Undirected.cs"
Size: 34897 FileType: Regular File
Mode: (0644/-rw-r--r--) Uid: ( 501/ lucien) Gid: ( 20/ staff)
Device: 44,21 Inode: 3104 Links: 1
Access: Fri Feb 10 17:15:18 2012
Modify: Thu Feb 9 17:38:18 2012
Change: Fri Feb 10 17:15:18 2012
> Because they're different, Git thinks they're different and so notes
> the change - but it's easily fixable by setting the trustctime off,
> as you noted.
I know it's easily fixable, but the fact that we need to use a fix at
all is troubling, and sounds like something that could be fixed
somehow.
Alex Blewitt
Weird, I've not seen that before. I wonder what's going on under the covers.
Here's where the timestamps are decoded:
https://github.com/alblue/mac-zfs/blob/master/usr/src/uts/common/fs/zfs/zfs_vnops.c#L2704
I don't see anything obvious there, but there may be a 'setattr' call happening as well for some reason that has a side-effect of setting the ctime.
Here's where the time gets set if it's passed in with the create time:
https://github.com/alblue/mac-zfs/blob/master/usr/src/uts/common/fs/zfs/zfs_vnops.c#L3205
Feel free to have an eyeball through there and/or debug if you want to get deeper - patches welcome :)
Alex