Started (notes) 2007-07-06. Reading the Solaris ZFS Administration Guide from Solaris x86 2006-11. ZFS: takes whole disks, slices, or files, sorts out direct use or mirroring or improved raid5/6 ('raidZ'), and makes a 'pool' from this collection of devices. Different filesystems can be created within the pool, each inheriting properties and automatically being mounted when needed; typically, have a separate filesystem for each homedir etc. It's transaction-based, with atomic operations, and allows snapshots (copy on write) to capture consistent states of a filesystem. The management command seems indeed simple -- surprisingly so for anything associated with Solaris. The permissions are more NFSv4 than POSIX based -- 'finer granularity'. The redundancy has 'self-healing' to replace data on bad blocks. Checksumming and compression can be included for a filesystem. There is not preallocation for the filesystems, and they can scale vastly. Web admin: /usr/sbin/smcwebserver start https://system-name:6789/zfs Make a pool called 'tank' from a single physical disk, then make a single fs below this. zpool create tank c1t0d0 zfs create tank/fs Do mirroring of devices. zpool create tank mirror c1t0d0 c1t1d0 Use 'raidZ' with single parity (raidz2 for double): zpool create tank raidz c1t0d0 c2t0d0 c3t0d0 c4t0d0 Destroy a pool, and free its component devices. zpool destroy tank Add another (mirrored) 'top level virtual device' to an existing pool, to give immediate increase in the available space in the pool: zpool add tank mirror c2t1d0 c2t2d0 Add new device c2t1d0 to the same set (mirror, etc.) as the existing c1t1d0 within pool 'tank': zpool attach tank c1t1d0 c2t1d0 Detach this device (not poss. if no redundancy): zpool detach zeepool c2t1d0 Bring a device offline (if redundancy permits) zpool offline tank c1t0d0 (can use -t option to make it temporary, i.e. non-persistent across reboots) Bring the device back into the pool by: zpool online tank c1t0d0 which causes syncing of the device to the pool's current state; this requires the device to be recognised as having been in the pool, i.e. off/on-line CAN'T be used to change a device. A device can be replaced by another by: zpool replace tank c1t1d0 c1t2d0 Add hot spares by: zpool add -f tank spare c1t3d0 c2t3d0 See the current pool status by: zpool status -x tank (or omit -x for shorter detail). See all pools by zpool list and I/O data by: zpool iostat [-v] Moving a pool between host machines is done by zpool export name (move devices across) zpool import name The filesystems themselves within a pool can be nested, with inheritance of properties (which can be overridden). It's pretty much like creating directories! All parents up to a new filesystem root must exist. The naming is based on pool/[path/]name. Set properties of ZFS filesystems, inherited by ones created below these points. zfs set mountpoint=/export/zfs tank/home zfs set sharenfs=on tank/home zfs set compression=on tank/home Make some below the first FS point: zfs create tank/home/bonwick zfs create tank/home/billm zfs set quota=10G tank/home/bonwick zfs get quota tank/home/bonwick zfs get all tank zfs list Recursive listing of ZFS roots: zfs list -r Remove an filesystem: zfs destroy /name/of/zfs There are many properties that can be set, and these include the common conventional filesystem settings such as readonly, noexec, as well as sharenfs, snapdir and other ZFS-specific ones. The -H option to zfs get make output suitable for scripting: no headers, and single tab delimiters. Default mounting is automatic as the local system service. Setting mountpoint=legacy for a zfs fs allows conventional [v]fstab mounting. Rather like linux utils, the remount option allows a change in settings for a mounted fs: zfs mount -o remount,noatime tank/home/perrin Backup by snapshot is done as: zfs snapshot tank/home/nt@snapshotname or recursively for a whole set of ZFSs as zfs snapshot tank/home@snapshotname A snapshot can be removed as zfs destroy tank/home/nt@snapshotname and this can also be recursive. The main ZFS can't be removed (destroyed) if it has existing shapshots. Snapshots within the same ZFS can be renamed as: zfs rename tank/home/nt@083006 tank/home/nt@today List snapshots as zfs list -t snapshot or zfs list -r -t snapshot -o name,creation tank/home Restore ('rollback') the main ZFS to a snapshot by: zfs rollback tank/home/nt@tuesday Cloning allows another ZFS root based on a snapshot. Promotion of a clone allows the source of the snapshot to be removed, and the clone becomes a true ZFS itself. The 'send' option allows a snapshot to be serialised for archiving to an external space: zfs send tank/nt@0830 > /bkups/nt.083006 or, incrementals only: zfs send -i tank/nt@0829 tank/nt@0830 > /bkups/dana.today and restore from external space as: zfs receive tank/nttmp@today < /bkups/nt.083006 The NFSv4-style ACLs of ZFS are managed and listed through the standard utilities such as chmod and ls, rather than through the [sg]etfacl commands. They allow different inheritance structures, and finer control over such permissions as delete, list directory, list ACL, etc. There is no fsck utility, as the transactional design is such that there's no expected problem other than uncorrectable corruption caused by hardware problems. 'Scrubbing' is performed to check the goodness of the whole available space on the devices: zpool scrub tank - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - It would be interesting to try this out sometime. Best candidate is pingvin (to be penguin) at KTH, before it returns to active duty! That offers 7 whole disks besides the system disk. Try raidZ on a typical /home pool, with NFS, and see what speeds are obtained with raidz and raidz2. This isn't practical for the final system if that is to run samba, dns, etc., but it's jolly tempting (the snapshots, in particular, but also the quick 'resilvering' of data after device restoration, and the independence of home directories and the working NFSv4.