From owner-freebsd-questions@freebsd.org Sun Jun 12 21:58:29 2016 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 19A15AF15E2 for ; Sun, 12 Jun 2016 21:58:29 +0000 (UTC) (envelope-from brandon.wandersee@gmail.com) Received: from mail-it0-f53.google.com (mail-it0-f53.google.com [209.85.214.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E2B1229E4 for ; Sun, 12 Jun 2016 21:58:28 +0000 (UTC) (envelope-from brandon.wandersee@gmail.com) Received: by mail-it0-f53.google.com with SMTP id a5so35346163ita.1 for ; Sun, 12 Jun 2016 14:58:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:date:message-id:mime-version; bh=Su6jbrN1x2Tj9l5dTLgs97uUqeCoQoI42iXCpJo+pYA=; b=bBxJl3mke8EtCgMWoZl1wxFzv5frqvBJsTQQcnHjEAxlUassRj4GeDbxdoqYrRr5DV DJexJBzdpkOjm36AWhBki+cvksEiM6EREjDnlI8xpxOJ2APbcr8YXVgs/NFTqCBAw9Xe omdr5AIM028D4KushvliDR121j+MngzjCWZ45z5UbqDwKdJXiLXLoj9goVqyCMX4f2XY GPyqk2moAx1iXQijsYt0tiARxcn0DRr0tD2Dt3EclIBsw5sRQe4aOkSLUJRSpFngFFWb 0KotZUpBg847zHf4VWQP+bq9ejtKu43pJze5VpyBsRDaYAUBqFbDp30nN3Epr4Ee6DuX 68+A== X-Gm-Message-State: ALyK8tLbHbWzwgz7uXT7uC9TH6Cea2K+v6kKP5I8DiR2tNFQ1y8adNKLsV8E59ZGNlfMKA== X-Received: by 10.36.214.4 with SMTP id o4mr12989729itg.14.1465768701528; Sun, 12 Jun 2016 14:58:21 -0700 (PDT) Received: from WorkBox.Home.gmail.com (174-30-251-248.mpls.qwest.net. [174.30.251.248]) by smtp.gmail.com with ESMTPSA id p199sm4930728itc.2.2016.06.12.14.58.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Jun 2016 14:58:20 -0700 (PDT) References: User-agent: mu4e 0.9.16; emacs 24.5.1 From: Brandon J. Wandersee To: Yuri Cc: FreeBSD Questions Subject: Re: ZFS: Is 'zpool add' really irreversible? In-reply-to: Date: Sun, 12 Jun 2016 16:58:19 -0500 Message-ID: <86shwiax38.fsf@WorkBox.Home> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2016 21:58:29 -0000 Yuri writes: > This is very surprising that something as simple as that can't be undone. `zpool add` adds *virtual* devices to a *pool*, while `zfs attach` adds physical devices to a mirrored device. So individual disks can be added to and removed from mirrored virtual devices, but virtual devices cannot be removed from a pool. A ZFS pool is striped across all virtual devices included in the pool, with data and metadata in the pool distributed across the physical devices that make up those virtual devices, in order to improve performance, redundancy, or both. Adding a virtual device doesn't merely make more space available---that virtual device is actually in use from the moment it is added, beginning with a resilver operation. >From the perspective of ZFS, removing a virtual device would be similar in effect to removing a drive from your machine, sawing it in half, and putting it back in. There's still data on that half-disk, but you'll never get to it. ZFS tries the same thing every time a pool is imported, searching for all devices that belong to it and panicking when devices/data that should exist do not. So yes, once you've added a virtual device to a pool it is a permanent part of the pool. You should plan out your storage to accommodate your needs for the foreseeable future---typically, you would actually make the pool larger than what you need right now in anticipation of eventially adding more data. ZFS was essentially designed as a long-term use, "archival" filesystem; shrinking a pool isn't something that would ever really happen in situations where ZFS is appropriate. -- :: Brandon J. Wandersee :: brandon.wandersee@gmail.com :: -------------------------------------------------- :: 'The best design is as little design as possible.' :: --- Dieter Rams ----------------------------------