Bug #3835


zfs need not store 2 copies of all metadata

Added by Christopher Siden almost 10 years ago. Updated about 9 years ago.

zfs - Zettabyte File System
Start date:
Due date:
% Done:


Estimated time:
Gerrit CR:
External Bug:


From Matt Ahrens's bug report at Delphix:

Add a new zfs property, "redundant_metadata" which can have values "all" or
"most".  The default will be "all", which is the current behavior.  Setting to
"most" will cause us to only store 1 copy of level-1 indirect blocks of user
data files.

From the new man-page entry:

redundant_metadata=all | most
         Controls what types of metadata are stored  redundantly.
         ZFS  stores an extra copy of metadata, so that if a sin-
         gle block is corrupted, the amount of user data lost  is
         limited.   This  extra copy is in addition to any redun-
         dancy provided at the pool level (e.g. by  mirroring  or
         RAID-Z),  and  is in addition to an extra copy specified
         by the copies property (up to a total of 3 copies).  For
         example   if   the   pool  is  mirrored,  copies=2,  and
         redundant_metadata=most, then ZFS  stores  6  copies  of
         most metadata, and 4 copies of data and some metadata.

         When set to all, ZFS stores an extra copy of  all  meta-
         data.   If a single on-disk block is corrupt, at worst a
         single block of user data  (which  is  recordsize  bytes
         long) can be lost.

         When set to most, ZFS stores an extra copy of most types
         of  metadata.   This  can  improve performance of random
         writes, because less metadata must be written.  In prac-
         tice,  at  worst  about  100 blocks (of recordsize bytes
         each) of user data can be lost if a single on-disk block
         is corrupt.  The exact behavior of which metadata blocks
         are stored redundantly may change in future releases.

         The default value is all.

Related issues

Related to illumos gate - Bug #4390: i/o errors when deleting filesystem/zvol can lead to space map corruptionClosedChristopher Siden2013-12-11

Actions #1

Updated by Rich Lowe almost 10 years ago

We have heretofore avoided underscores in property names, it seems consistency would be avoiding it here too. (I'm sorry I'm painting this shed, but maybe doing it in the bug keeps things quieter other than me?)

Actions #2

Updated by Matthew Ahrens almost 10 years ago

That isn't quite true: "defer_destroy" has existed since at least 2009.

But I'm open to alternative names. What would you propose?

Actions #3

Updated by Rich Lowe almost 10 years ago

I'd missed snapshot-specific properties when I looked, my apologies.

I was looking at both 'zfs get all' and 'zpool get all', the latter has underscores in feature names, but the former has none at all. I was just suggesting the same name with the underscore removed, which seems to be no more unwieldy than 'casesensitivity' or 'logicalreferenced' or 'usedbydatasets'. It's not a big deal, I was just shooting for consistency, which as you point out, we already lack.

Actions #4

Updated by Electric Monk about 9 years ago

  • Status changed from In Progress to Closed

git commit edf345e6b8342e8627ec20ce821a977a62cee19d

commit  edf345e6b8342e8627ec20ce821a977a62cee19d
Author: Matthew Ahrens <>
Date:   2014-05-23T16:21:07.000Z

    3835 zfs need not store 2 copies of all metadata
    Reviewed by: George Wilson <>
    Reviewed by: Adam Leventhal <>
    Reviewed by: Dan McDonald <>
    Approved by: Richard Lowe <>


Also available in: Atom PDF