Many thanks for the quick reply, Eric. ZFS is quite awesome, but also awesomely complicated.
What did you mean with >For *filesystems*, you can consult the per-pool history. Is this the vdev label uberblock / MOS thing? > It is part of the MOS (meta object set), which is the root of all > pool-wide metadata. I'm still trying to work out where the MOS can be found on disk. The uberblock points to it, but is it outside the vdev label? The diagram on p. 32 of the "ZFS On-Disk Specification" is a bit ambiguous here. Where does the file-system metadata end and the files / file metadata / directories begin? Regards Mark On Wednesday 25 July 2007 18:08, Eric Schrock (Eric Schrock <eric.schrock at sun.com>) may have written: > On Wed, Jul 25, 2007 at 01:11:54PM +0200, Mark Furner wrote: > > * ZFS has a legacy mode where mounts are handled by /etc/vfstab or a > > default mode where pools are automounted by ZFS. If you use /etc/vfstab > > and switch off the automatic mount at boot, the ZFS partitions won't be > > touched unless manually mounted. > > > > * zpool.cache appears to be a record of the creation, maintenance and > > destruction of ZFS pools (spa_config.h). > > > > * According to spa_config.h and libzfs_config.c, zpool.cache is part of > > the SPA layer, made up of nvlist objects. > > > > * spa_history.c mentions a history log ring buffer where the creation and > > subsequent actions to an SPA object are recorded. > > > > QUESTIONS > > > > * Can someone confirm whether the info above is correct? > > Sort of. As its name implies, it is a "cache" of pool configurations > active on the system. ZFS is designed such that all information needed > to access any pool is present on the disks themselves. However, without > a cache file we would need to inspect (i.e. read the zpool labels from) > every Solaris device on boot, which would be quite expensive. And we > wouldn't be able to have pools based on files. If this file is > destroyed or lost, the pool can still be opened via 'zpool import', but > this may be a slower operation. > > > * How persistent is the information in zpool.cache after zpools have been > > destroyed? > > zpool.cache only keeps track of active pools on the system. > > > * I'm still looking for a C-struct type definition of the zpool.cache > > records. Can someone point me in the right direction? > > Sorry, there's no good reference here. The contents have grown > haphazardly over time, and there's no definitive reference. You can > easily examine the contents of the cache file with 'zdb -C'. In the > source code, you'll want to look at the ZPOOL_CONFIG_* definitions in > zfs.h and spa_config_generate(). > > > * Are there any *other* records left on the host regarding the > > creation/maintenance/destruction of a ZFS file system? > > For *filesystems*, you can consult the per-pool history. There is no > record for pool creation or destruction, though there is an open RFE to > have this incorporated in the Solaris auditing system. > > > * Where does the SPA history log land on-disk? Is it the zpool.cache of > > the host, somewhere else on the host or part of vdev label / ZFS file > > system? > > It is part of the MOS (meta object set), which is the root of all > pool-wide metadata. > > > * "ZFS On-Disk Specification" is described as a draft, dated 22 August > > 2006. Is there anything more recent available? > > Sadly, no. It could probably use some love but most of the engineers > have been too busy to keep the document up to date with ongoing changes. > > - Eric > > -- > Eric Schrock, Solaris Kernel Development > http://blogs.sun.com/eschrock -- x-x-x-x-x-x-x-x-x-x-x-x-x Mark Furner, PhD L?rchenstr. 39 CH 8400 Winterthur Switzerland T. 0041 (0)78 641 15 92 E. mark.furner at gmx.net
