From owner-freebsd-fs@FreeBSD.ORG Fri Nov 9 11:44:46 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 BC79070B for ; Fri, 9 Nov 2012 11:44:46 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 34BA18FC12 for ; Fri, 9 Nov 2012 11:44:45 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.5/8.14.5) with ESMTP id qA9BicZA067717 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 9 Nov 2012 13:44:38 +0200 (EET) (envelope-from daniel@digsys.bg) Message-ID: <509CECA6.70308@digsys.bg> Date: Fri, 09 Nov 2012 13:44:38 +0200 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.10) Gecko/20121029 Thunderbird/10.0.10 MIME-Version: 1.0 To: Nikolay Denev Subject: Re: zfs remove vdev functionality References: <509BF0A2.2050600@digsys.bg> <393C72B3-7231-47C6-ABD2-1C6BA166ED11@gmail.com> In-Reply-To: <393C72B3-7231-47C6-ABD2-1C6BA166ED11@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org 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 11:44:47 -0000 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. 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