From owner-freebsd-fs@FreeBSD.ORG Fri Nov 9 13:17:21 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 71A3515A for ; Fri, 9 Nov 2012 13:17:21 +0000 (UTC) (envelope-from freebsd-fs@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 1EBA08FC08 for ; Fri, 9 Nov 2012 13:17:20 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TWoSd-0004S6-Pr for freebsd-fs@freebsd.org; Fri, 09 Nov 2012 14:17:27 +0100 Received: from dyn1219-66.wlan.ic.ac.uk ([129.31.219.66]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Nov 2012 14:17:27 +0100 Received: from johannes by dyn1219-66.wlan.ic.ac.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Nov 2012 14:17:27 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Johannes Totz Subject: Re: zfs remove vdev functionality Date: Fri, 09 Nov 2012 13:17:08 +0000 Lines: 45 Message-ID: References: <509BF0A2.2050600@digsys.bg> <393C72B3-7231-47C6-ABD2-1C6BA166ED11@gmail.com> <509CECA6.70308@digsys.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: dyn1219-66.wlan.ic.ac.uk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 In-Reply-To: <509CECA6.70308@digsys.bg> X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 13:17:21 -0000 On 09/11/2012 11:44, Daniel Kalchev wrote: > > > On 08.11.12 21:39, Nikolay Denev wrote: >> On Nov 8, 2012, at 7:49 PM, Daniel Kalchev wrote: >> >>> I was thinking on how to implement vdev removal on ZFS and came to >>> this idea: >>> >>> If we can have an per-vdev flag that prohibits new allocations on the >>> vdev, but permits reads and frees - then we could mark so the vdev >>> we intend to remove form the zpool and issue an scrub-like command >>> that will rewrite all blocks allocated form that particular vdev. >>> Since ZFS is COW, this will effectively move all blocks off that "no >>> write" vdev and we can now detach it. >>> >>> All this could be implemented with the new ZFS feature flags, so no >>> version bumps etc are necessary. >>> >>> Is there something I didn't think of? >> I don't think this will be that easy, because of snapshots, clones etc. > > The snapshots etc are above the block allocator level, at which this > should be implemented. Are you sure about this? Because exactly the reason that snapshots are built on the actual block pointer addresses makes the whole BP-rewrite so difficult. > I believe the BP rewrite is the same concept, except it was probably > intended to increment the zpool version etc. My idea is to make this > feature independent of the on-disk format. The only more involving > change would be the "detach vdev" part. > > A side effect of this might be the ability to re-balance the data over > all vdevs, which is an issue currently, especially if you add new vdevs > to an reasonably full zpool. > > Daniel > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >