zfs discuss - Feb 2007 - ZFS limits on zpool snapshots

The ZFS On-Disk specification and other ZFS documentation describe the labeling
scheme used for the vdevs that comprise a ZFS pool.  A label entry contains,
among other things, an array of uberblocks, one of which will point to the
active object set of the pool it is a part of at a given instant (according to
documentation, the active uberblock for a given pool could be located in the
uberblock array of any vdev participating in the pool at a given instant, and is
subject to relocation from vdev to vdev as the uberblock for the pool is
recreated in an update).  Recreation of the active uberblock would occur, for
example, if we took a snapshot of the pool and changes were then made anywhere
in the pool.  Since a new uberblock is required in this snapshot scenario, and
since it appears that the uberblocks are treated as a kind of circular list
across vdevs, it seems to me that the number of available snapshots we could
have of a pool at any given instant would be strictly limited to the number of
available uberblocks in the vdevs of the pool (128 uberblocks per vdev, if I
have that straight).  Is this truly the case or am I missing something here ?
 
 
This message posted from opensolaris.org

zfs-discuss-bounces at opensolaris.org wrote on 02/01/2007 01:17:15 PM:
> The ZFS On-Disk specification and other ZFS documentation describe
> the labeling scheme used for the vdevs that comprise a ZFS pool.  A
> label entry contains, among other things, an array of uberblocks,
> one of which will point to the active object set of the pool it is a
> part of at a given instant (according to documentation, the active
> uberblock for a given pool could be located in the uberblock array
> of any vdev participating in the pool at a given instant, and is
> subject to relocation from vdev to vdev as the uberblock for the
> pool is recreated in an update).  Recreation of the active uberblock
> would occur, for example, if we took a snapshot of the pool and
> changes were then made anywhere in the pool.  Since a new uberblock
> is required in this snapshot scenario, and since it appears that the
> uberblocks are treated as a kind of circular list across vdevs, it
> seems to me that the number of available snapshots we could have of
> a pool at any given instant would be strictly limited to the number
> of available uberblocks in the vdevs of the pool (128 uberblocks per
> vdev, if I have that straight).  Is this truly the case or am I
> missing something here ?
>
It is my understanding that during the snapshot uberblock pool change
creation chain the old uberblock is treated as a separate entity and not
tied to the new uberblock list.

I am sure I will be corrected if I am reading the flow wrong.

Thanks,
-Wade

> Recreation of the active uberblock would occur, for example, if we
> took a snapshot of the pool and changes were then made anywhere in the
> pool.
The uberblock is updated quite often, not just on snapshots.
> Since a new uberblock is required in this snapshot scenario,
> and since it appears that the uberblocks are treated as a kind of
> circular list across vdevs, it seems to me that the number of
> available snapshots we could have of a pool at any given instant would
> be strictly limited to the number of available uberblocks in the vdevs
> of the pool (128 uberblocks per vdev, if I have that straight).  Is
> this truly the case or am I missing something here ?
Are you talking about normal ZFS filesystem snapshots or something else?
The new uberblock will point to all filesystem snapshots.  The old
copies would never normally be referenced.

-- 
Darren Dunham                                           ddunham at taos.com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

As far as I know the recalled on paper number of snapshots you can have in a
filesystem is 2^48.
 
 
This message posted from opensolaris.org

Bill Moloney wrote:
> The ZFS On-Disk specification and other ZFS documentation describe
> the labeling scheme used for the vdevs that comprise a ZFS pool.  A
> label entry contains, among other things, an array of uberblocks, one
> of which will point to the active object set of the pool it is a part
> of at a given instant (according to documentation, the active
> uberblock for a given pool could be located in the uberblock array of
> any vdev participating in the pool at a given instant, and is subject
> to relocation from vdev to vdev as the uberblock for the pool is
> recreated in an update).  
Correct.
> Recreation of the active uberblock would
> occur, for example, if we took a snapshot of the pool and changes
> were then made anywhere in the pool.  
It isn''t possible to snapshot the pool.  You can snapshot filesystems 
within the pool (even all filesystems, with ''zfs snapshot -r 
<poolname>'').  Some of the diagrams you may have seen are
somewhat
misleadingly simple, so I can see how this could be confusing.

When we snapshot a filesystem, we keep multiple copies of the 
filesystem''s root block, which just some interior node in the tree of 
all blocks.  See the description of datasets in the on-disk spec, and 
dsl_dataset.c/h.

--matt

ps. to answer your question, yes, you really can have a zillion snapshots.