[OpenIndiana-discuss] Last change in zfs filesystem

[Jim Klimov]

2012-09-25 11:52, Armin Maier wrote:
> Hello, is there an easy way wo find out when the last update occured to
> an zfs filesystem, my goal is to only make a backup of a filesystem when
> something has changed. At this time i make it in a command pipe with
> "find ... | sort ... | head | awk" what takes a lot of time if the
> filesystem holds a lot of files.

As an idea, I think it may be possible to use (and script-wrap)
the ZDB (ZFS DeBugger) to get the last TXG and maybe timestamp
of the ZFS dataset's root block update, roughly like this (as
root; use pfexec/sudo for non-roots):

# zdb -dddddd rpool/export/home 0
Dataset rpool/export/home [ZPL], ID 76, cr_txg 51, 5.41M, 11 objects, 
rootbp DVA[0]=<0:a41b73a00:200> DVA[1]=<0:262216a00:200> [L0 DMU objset] 
fletcher4 lzjb LE contiguous unique double size=800L/200P 
birth=1472850L/1472850P fill=11 
cksum=129a921cc8:63da9a79406:11b5c24f24f25:23431dd69d5e29

     Object  lvl   iblk   dblk  dsize  lsize   %full  type
          0    7    16K    16K    16K    16K   34.38  DMU dnode 
(K=inherit) (Z=inherit)
         dnode flags: USED_BYTES
         dnode maxblkid: 0
Indirect blocks:
                0 L6       0:a41b69600:400 0:261d98a00:400 4000L/400P 
F=11 B=1472850/1472850
                0  L5      0:a41b68e00:400 0:261d94200:400 4000L/400P 
F=11 B=1472850/1472850
                0   L4     0:a41b68600:400 0:261d93a00:400 4000L/400P 
F=11 B=1472850/1472850
                0    L3    0:a41b67e00:400 0:261d93200:400 4000L/400P 
F=11 B=1472850/1472850
                0     L2   0:a41b67600:400 0:261d90e00:400 4000L/400P 
F=11 B=1472850/1472850
                0      L1  0:a41b67200:400 0:261d90a00:400 4000L/400P 
F=11 B=1472850/1472850
                0       L0 0:a415b5800:800 0:260715a00:800 4000L/800P 
F=11 B=1472850/1472850

                 segment [0000000000000200, 0000000000001800) size 5.50K

I limited the output (and time consumption) by specifying an object
which always exists (inode #0); you can further limit the parsing by
taking just the first line (zdb ... | head -1).
In particular, above we can see that the "birth TXG numbers" of the
current block instance are 1472850 for logical assignment and physical
write to disk.

If I'm not mistaken, any update to any object in the filesystem
should change its block pointer tree upwards to pool uberblock,
passing through the dataset's "root block". Note this may also
include updates from just accessing dirs/files if your atime=on
(as it is by default), as well as creation of snapshots.

Also note that running ZDB on a live pool is discouraged in the
docs, because it does not guarantee consistency (things may
change while ZDB is collecting data).

Hope this helps,
//Jim Klimov