zfs send -R [PSARC/2007/574 FastTrack timeout 10/10/2007]
Matthew Ahrens
ahrens at jurassic-x4600.sfbay.sun.com
Wed Oct 3 10:24:39 PDT 2007
Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI
This information is Copyright 2007 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
zfs send -R
1.2. Name of Document Author/Supplier:
Author: Matthew Ahrens
1.3 Date of This Document:
03 October, 2007
4. Technical Description
This case adds new flags to "zfs send". The stability of the flags are
committed, and the release binding is patch/micro.
A. INTRODUCTION
Currently, "zfs send" can send only a single snapshot at a time. To
send all the snapshots of a given filesystem, or snapshots of multiple
filesystems, would require multiple "zfs send" commands. Additionally,
"zfs send" can not transfer property settings, nor can it replicate
namespace changes (eg, snapshot/fs renaming or deletion).
This case enhances "zfs send" to implement these features.
B. DESCRIPTION
This case adds several new capabilities to "zfs send":
1. zfs send -I @snapA pool/fs at snapD
Sends all incrementals from snapA to snapD (ie, snapA to snapB, snapB to
snapC, and snapC to snapD).
2. zfs send -[iI] pool/fs at origin pool/clone at snap
Sends an incremental stream from the origin snapshot to create a clone.
(To be received, the origin snapshot must already exist on the receiving
end.)
3. zfs send -R pool/fs at snap
Sends a "replication" stream, which will replicate pool/fs, and all
descendant filesystems, up to the named snap. When received, all
properties, snapshots, descendent filesystems, and clones will be
preserved.
4. zfs send -R -[iI] @snapA pool/fs at snapD
Sends an "incremental replication" stream. Changes to properties, and
snapshot and filesystem renames and destroys will be preserved. When
receiving, if -F is not specified, then destroys will be ignored. (-F
also retains its "rollback if necessary" meaning.) As with other
(non-R) -i/-I cases, if -I is used, all snapshots between snapA and
snapD will be sent; if -i is used, only snapD (for all descendents) will
be sent.
Note, to receive any of these new type of "zfs send" streams, the
receiving system must be running a software version capable of sending
them. Ie, the stream version is incremented. However, no on-disk
changes are required, so these streams can be received into old-version
pools. There are no changes needed to the user interface for "zfs recv"
to receive these streams.
C. MANPAGE CHANGES
TBD, based on the above text.
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
ON
6.5. ARC review type: FastTrack
6.6. ARC Exposure: open
More information about the opensolaris-arc
mailing list