The following case is about to go to PSARC. Comments are welcome.
eric
(i'll be going out of town tonight, so apologies if i can't respond
immediatley to feedback)
A. DESCRIPTION
Add the capability of ZFS to log commands to disk (peristently). Only
successful commands are logged. At first, only zpool(1M) and zfs(1M)
subcommands will be logged, but we allow the capability to log other
(internal) events - such as when a scrub or resilver started/finished.
Adding a command history log to ZFS can save a lot of work for Sun
when resolving support calls. Without this, we are relying on what
customers *think* they typed versus what they actually typed. We
can then immediatley know if the problem was with the customer's
admin or with our product.
The output is retrievable via a new subcommand (see below) so that
customer's can potentially avoid calling Sun by realizing their
own mistakes.
B. NEW SUBCOMMANDS
A new subcommand will be added to zpool(1M), 'zpool history':
zpool history [pool]
By default, this command will report the entire command history
of all active pools:
# zpool history
History for 'hewitt':
2006-04-27T10:33:50 zpool create -f hewitt c1t1d0s3
2006-04-27T10:33:51 zfs create hewitt/love
2006-04-27T10:33:51 zfs set recordsize=16k hewitt
2006-04-27T10:33:51 zfs create -V 10m hewitt/vol1
2006-04-27T10:33:53 zfs snapshot [EMAIL PROTECTED]
2006-04-27T10:33:54 zfs destroy hewitt/vol1
2006-04-27T10:33:56 zfs recv hewitt/[EMAIL PROTECTED]
2006-04-27T10:33:57 zfs set mountpoint=/bogus hewitt/ready_to
2006-04-27T10:34:00 zfs set mountpoint=/hewitt/ready_to hewitt/ready_to
History for 'jen':
2006-04-27T10:38:36 zpool create jen mirror /tmp/a.txt /tmp/b.txt
#
If you specify a pool (or list of pools), this command will only
display the command history of the specified pools:
# zpool history jen
History for 'jen':
2006-04-27T10:38:36 zpool create jen mirror /tmp/a.txt /tmp/b.txt
#
The time is displayed in ISO 8601 format.
In the future, we are looking to add additional data to log and retrieve, such
as hostname (for shared storage) or username (for delegated administration).
C. LOGGED SUBCOMMANDS
Only subcommands that modify state are logged.
For zpool(1M), the subcommands that are logged are:
zpool create
zpool destroy
zpool add
zpool offline
zpool online
zpool attach
zpool detach
zpool replace
zpool scrub
zpool export
zpool import
zpool clear
zpool upgrade
For zpool(1M), the subcommands that are not logged are:
zpool list
zpool status
zpool iostat
For zfs(1M), the subcommands that are logged are:
zfs create
zfs destroy
zfs clone
zfs rename
zfs snapshot
zfs rollback
zfs set
zfs inherit
zfs receive
For zfs(1M), the subcommands that are not logged are:
zfs list
zfs get
zfs mount
zfs umount
zfs share
zfs unshare
zfs send
'zfs (un)mount' and 'zfs (un)share' are purposely left as they could
needlessly fill up a log: imagine a server with 10,000 file systems,
all shared via NFS - that would put 20,000 logged commands into the
log.
D. Log Details
In the kernel, the log is implemented as a ring buffer. The maximum size
is 32MB (enough space for a single indirect block with 128KB blocks). For
smaller pools, the maximum size is capped at 1% of the pool size (size
determined at pool creation time), but the size is always at least 128KB.
The administrator doesn't have direct control of how big the ring buffer is.
In its current implementation, ZFS cannot survive a write failure. As
a subcommand and its corresponding command history log I/O are both done in
the same transaction group, either both succeed or neither succeed with the
current implementation of ZFS.
In the future, ZFS will be improved to handle write failues. When that
happens, if a subcommand was successfully written to disk, but the command
history log I/O failed, then a counter of failed log write I/Os is incremented.
The results of which are seen via 'zpool history':
# zpool history
zpool: warning: 37 log write errors occurred -- some history missing
...
E. MANPAGE CHANGES
Diffs for zpool(1M):
***************
*** 44,49 ****
--- 44,51 ----
zpool import [-d dir] [-f] [-a]
+ zpool history [pool] ...
+
DESCRIPTION
The zpool command configures ZFS storage pools. A storage
pool is a collection of devices that provides physical
***************
*** 213,218 ****
--- 215,223 ----
is "/", rather than the normal default "/pool".
Subcommands
+ All subcommands that modify state are logged persistenly to
+ the pool in their original form.
+
The zpool command provides subcommands to create and destroy
storage pools, add capacity to storage pools, and provide
information about the storage pools. The following subcom-
***************
*** 708,713 ****
--- 713,727 ----
potentially active.
+
+
+ zpool history [pool]
+
+ Displays the command history of the specified pools (or all
+ pools if no pool is specified).
+
EXAMPLES
Diffs for zfs(1M):
***************
*** 748,753 ****
--- 748,757 ----
Using a ZFS volume as a dump device is not supported.
SUBCOMMANDS
+
+ All subcommands that modify state are logged persistenly to
+ the pool in their original form.
+
zfs ?
Displays a help message.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
