Last active
January 18, 2021 03:09
-
-
Save mgerdts/2eeb60421e46dcbc24b4ce5adc7642ca to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| X-Gmail-Received: cd1f5334be7e07c5ae660415a92dd8d7db52e9a8 | |
| Delivered-To: mgerdts@gmail.com | |
| Received: by 10.90.82.20 with SMTP id f20cs699047agb; | |
| Mon, 11 Sep 2006 16:46:36 -0700 (PDT) | |
| Received: by 10.70.46.1 with SMTP id t1mr7121092wxt; | |
| Mon, 11 Sep 2006 16:46:15 -0700 (PDT) | |
| Return-Path: <zfs-discuss-bounces@opensolaris.org> | |
| Received: from mail.opensolaris.org (oss-mail1.opensolaris.org [72.5.123.71]) | |
| by mx.gmail.com with ESMTP id h18si9496273wxd.2006.09.11.16.46.08; | |
| Mon, 11 Sep 2006 16:46:15 -0700 (PDT) | |
| Received-SPF: pass (gmail.com: best guess record for domain of zfs-discuss-bounces@opensolaris.org designates 72.5.123.71 as permitted sender) | |
| Received: from oss-mail1.opensolaris.org (oss-mail1 [72.5.123.71]) by mail.opensolaris.org (Postfix) with ESMTP id 11355B1E27; Mon, 11 Sep 2006 16:46:07 -0700 (PDT) | |
| X-Original-To: zfs-discuss@opensolaris.org | |
| Delivered-To: zfs-discuss@opensolaris.org | |
| Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by mail.opensolaris.org (Postfix) with ESMTP id 13FBEB1A37 for <zfs-discuss@opensolaris.org>; Mon, 11 Sep 2006 16:46:05 -0700 (PDT) | |
| Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k8BNk4rX012307 for <zfs-discuss@opensolaris.org>; Mon, 11 Sep 2006 17:46:04 -0600 (MDT) | |
| Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k8BNk4sh015440 for <zfs-discuss@opensolaris.org>; Mon, 11 Sep 2006 16:46:04 -0700 (PDT) | |
| Received: from [192.168.1.10] (vpn-129-150-25-7.SFBay.Sun.COM [129.150.25.7]) by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k8BNk3G0012549 for <zfs-discuss@opensolaris.org>; Mon, 11 Sep 2006 16:46:04 -0700 (PDT) | |
| Message-ID: <4505F53B.9010506@sun.com> | |
| Date: Mon, 11 Sep 2006 16:46:03 -0700 | |
| From: Matthew Ahrens <Matthew.Ahrens@sun.com> | |
| User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) | |
| MIME-Version: 1.0 | |
| To: zfs-discuss@opensolaris.org | |
| Content-Type: text/plain; charset=ISO-8859-1; format=flowed | |
| Content-Transfer-Encoding: 7bit | |
| Subject: [zfs-discuss] Proposal: multiple copies of user data | |
| X-BeenThere: zfs-discuss@opensolaris.org | |
| X-Mailman-Version: 2.1.4 | |
| Precedence: list | |
| List-Id: zfs-discuss.opensolaris.org | |
| List-Unsubscribe: <http://mail.opensolaris.org/mailman/listinfo/zfs-discuss>, <mailto:zfs-discuss-request@opensolaris.org?subject=unsubscribe> | |
| List-Archive: <http://mail.opensolaris.org/pipermail/zfs-discuss> | |
| List-Post: <mailto:zfs-discuss@opensolaris.org> | |
| List-Help: <mailto:zfs-discuss-request@opensolaris.org?subject=help> | |
| List-Subscribe: <http://mail.opensolaris.org/mailman/listinfo/zfs-discuss>, <mailto:zfs-discuss-request@opensolaris.org?subject=subscribe> | |
| Sender: zfs-discuss-bounces@opensolaris.org | |
| Errors-To: zfs-discuss-bounces@opensolaris.org | |
| Here is a proposal for a new 'copies' property which would allow | |
| different levels of replication for different filesystems. | |
| Your comments are appreciated! | |
| --matt | |
| A. INTRODUCTION | |
| ZFS stores multiple copies of all metadata. This is accomplished by | |
| storing up to three DVAs (Disk Virtual Addresses) in each block pointer. | |
| This feature is known as "Ditto Blocks". When possible, the copies are | |
| stored on different disks. | |
| See bug 6410698 "ZFS metadata needs to be more highly replicated (ditto | |
| blocks)" for details on ditto blocks. | |
| This case will extend this feature to allow system administrators to | |
| store multiple copies of user data as well, on a per-filesystem basis. | |
| These copies are in addition to any redundancy provided at the pool | |
| level (mirroring, raid-z, etc). | |
| B. DESCRIPTION | |
| A new property will be added, 'copies', which specifies how many copies | |
| of the given filesystem will be stored. Its value must be 1, 2, or 3. | |
| Like other properties (eg. checksum, compression), it only affects | |
| newly-written data. As such, it is recommended that the 'copies' | |
| property be set at filesystem-creation time | |
| (eg. 'zfs create -o copies=2 pool/fs'). | |
| The pool must be at least on-disk version 2 to use this feature (see | |
| 'zfs upgrade'). | |
| By default (copies=1), only two copies of most filesystem metadata are | |
| stored. However, if we are storing multiple copies of user data, then 3 | |
| copies (the maximum) of filesystem metadata will be stored. | |
| This feature is similar to using mirroring, but differs in several | |
| important ways: | |
| * Different filesystems in the same pool can have different numbers of | |
| copies. | |
| * The storage configuration is not constrained as it is with mirroring | |
| (eg. you can have multiple copies even on a single disk). | |
| * Mirroring offers slightly better performance, because only one DVA | |
| needs to be allocated. | |
| * Mirroring offers slightly better redundancy, because one disk from | |
| each mirror can fail without data loss. | |
| It is important to note that the copies provided by this feature are in | |
| addition to any redundancy provided by the pool configuration or the | |
| underlying storage. For example: | |
| * In a pool with 2-way mirrors, a filesystem with copies=1 (the default) | |
| will be stored with 2 * 1 = 2 copies. The filesystem can tolerate any | |
| 1 disk failing without data loss. | |
| * In a pool with 2-way mirrors, a filesystem with copies=3 | |
| will be stored with 2 * 3 = 6 copies. The filesystem can tolerate any | |
| 5 disks failing without data loss (assuming that there are at least | |
| ncopies=3 mirror groups). | |
| * In a pool with single-parity raid-z a filesystem with copies=2 | |
| will be stored with 2 copies, each copy protected by its own parity | |
| block. The filesystem can tolerate any 3 disks failing without data | |
| loss (assuming that there are at least ncopies=2 raid-z groups). | |
| C. MANPAGE CHANGES | |
| *** zfs.man4 Tue Jun 13 10:15:38 2006 | |
| --- zfs.man5 Mon Sep 11 16:34:37 2006 | |
| *************** | |
| *** 708,714 **** | |
| --- 708,725 ---- | |
| they are inherited. | |
| + copies=1 | 2 | 3 | |
| + Controls the number of copies of data stored for this dataset. | |
| + These copies are in addition to any redundancy provided by the | |
| + pool (eg. mirroring or raid-z). The copies will be stored on | |
| + different disks if possible. | |
| + | |
| + Changing this property only affects newly-written data. | |
| + Therefore, it is recommended that this property be set at | |
| + filesystem creation time, using the '-o copies=' option. | |
| + | |
| + | |
| Temporary Mountpoint Properties | |
| When a file system is mounted, either through mount(1M) for | |
| legacy mounts or the "zfs mount" command for normal file | |
| D. REFERENCES | |
| _______________________________________________ | |
| zfs-discuss mailing list | |
| zfs-discuss@opensolaris.org | |
| http://mail.opensolaris.org/mailman/listinfo/zfs-discuss |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment