|
Description
|
xxxxx@xxxxx.com 2004-03-05
At present, you cannot use a /dev/zvol device as a dump device
(because it lacks a cb_dump entry point), nor can you use a file
in a ZFS filesystem (because we don't support VOP_DUMPCTL()).
We should support at least one of these options.
Here's where we are now:
1. Swapping to /dev/zvol is supported, and it works.
2. Swapping to a file in a ZFS filesystem is not supported.
Whether we add such support is TBD at the moment.
3. Dumping to /dev/zvol is not supported. We *could* make this work,
but it's a dubious proposition. In general, we want as little
software as possible between the injured kernel and the platter to
which it's writing. For this reason we recommend a dedicated dump
device, i.e. a slice large enough to hold the contents of memory
that isn't used for anything else, not even swap. See the NOTES
section of the dumpadm(1M) man page for more details.
The thing is, many people will want to stuff all the disks into one pool
and create things like dump devices virtually. We should give some
consideration to how we might make this work. There's already been work
along these lines for UFS to support CPR. Basically, UFS preallocates the
blocks for the file, and there's a callback that tells CPR the block list.
This allows CPR to write the file contents without going through the
filesystem at all. See VOP_DUMPCTL() and ufs_dumpctl() for details.
We could presumably do the same thing with either ZFS files or /dev/zvol
volumes. The only hitch is the checksums, but for the special case
of a dump device, maybe we could just use the null checksum function
for that object.
|
