Have "date modified" in .zfs/snapshot/<snapshot> reflect snapshot creation time

[wrouesnel]

Currently snapshots are simply presented as folders to the .zfs filesystem with what amount to dummy properties assigned for for things like their modification time or creation time. The workaround for dealing with snapshots most of the time is store their date in the name so one can easily look up when they were created (this also creates issues like requiring the user to ambiguously determine whether they want localtime or UTC etc.)

But, it would be far more convenient if their modification time (which would be an accurate way to use the term) would reflect the value of zfs get creation <snapshot> which stores in UTC the actual creation time of the snapshot.

This would let you sort all your snapshots by date easily by sorting on date modified, which is commonly visible in file managers.

[behlendorf]

This would be do able but it may come with a significant performance impact. Currently, all the snapshot names are listed in a ZAP object which gets traversed to create the list of directory entries. If we were to correctly set the mtime/ctime on these directories we would need to open each of these datasets which involves pulling some blocks off disk. This would probably be OK as long as we're careful to cache the dentries so each ls doesn't need to access the disk. Alternately, we could consider an on-disk format change and store these times in the snapshot ZAP.

[ahrens]

FYI, on illumos, if you stat(2) the snapshot (e.g. with "ls -l /pool/fs/.zfs/snapshot/today"), the snapshot will be mounted, and you'll get the info on the root directory of that snapshot. So you'll see the time that the root directory was modified, rather than the time the snapshot was created. I haven't heard reports of a problem with the performance of this operation.

It might be surprising for some of the stats on the snapshot dir to reflect the root directory, and others (ctime/mtime) reflect the snapshot itself.

[behlendorf]

Since we have an issue open for this let me explain exactly what's going on here. As @ahrens said on Illumos a stat(2) of the .zfs/snapshot/snap directory will cause the snapshot to be automatically mounted. This is done as part of the lookup operation so you'll never actually see the real mount point directory under the mounted snapshot so you always see the root inodes attributes. Which is nice.

Now under Linux we leverage the existing automount infrastructure which works slightly differently. Here the lookup operation triggered by the stat(2) will not trigger the mount, it will only create a virtual inode/dentry as the mount point. These entries need to have a atime/mtime/ctime set so we just grab the current time and use that. That's why when you do an ls -l in the .zfs/snapshot directory you don't see the expected times. It's not until you attempt to traverse in to one of these directories that the automount is triggered and the snapshot gets mounted. This is all done transparently in the kernel.

The upside to this approach is that an ls -l in the .zfs/snapshot directory which stats every entry won't cause every snapshot to be mounted. That could be 10's, 100's, or 1000's of snapshots which could potentially be bad and probably at best will be slow when you have a lot of snapshots. The downside is that on Linux you'll see all the mountpoints and they won't have the right attributes.

This could be fixed by essentially internally opening each dataset, peeking at the root inodes attributes, but stopping short of actually mounting anything. However, that's a little easier said than done with the existing APIs so we'd need to decide if it's worth it. We of course incur the disk I/O cost of the first stat(2) but after that the inode and dcache will be hot so this perhaps isn't so bad. Someone would just need to implement it.