From owner-freebsd-fs@FreeBSD.ORG Fri Nov 9 18:55:38 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 E77A35EB for ; Fri, 9 Nov 2012 18:55:38 +0000 (UTC) (envelope-from rincebrain@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9660C8FC16 for ; Fri, 9 Nov 2012 18:55:38 +0000 (UTC) Received: by mail-vb0-f54.google.com with SMTP id l1so5460095vba.13 for ; Fri, 09 Nov 2012 10:55:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mNcGKd/7LC+7Aae2YlQQiGq4AyL93pyVDksq/qHx3Ic=; b=Ozrga7OqDu+W6OUCnWxe7Cmdeg5RBBKoj7IYTd8iz0pBgv+hM8n5Ahmp7Jnmga3jYS qmLj9LHcmqEsy471EgjdPIuh2G6WIglyGwPqChNzyOjmD2KSw7pf90g8C9FUh2eS7yMd RUJ9/KkzEZxVsBmdtMZXs+hFBI5JfVLJ7B6IX/V3DLPVvK5dg29lgdI/Ws5pjrS6uEKg ++oxHEEzty7/U73azuDqy3tznRDBnMztXy4bFAmFE9QLjYnEPT9Ho1eob4tKb+4385Q+ fF/6C7VSltaT2J7iCys1gG1yb3lfBTaeaWw9VCCiQ3f7DENvT1KamPSIFbCMyUVZTbTu 9KUw== MIME-Version: 1.0 Received: by 10.52.77.101 with SMTP id r5mr9779049vdw.25.1352487337732; Fri, 09 Nov 2012 10:55:37 -0800 (PST) Received: by 10.58.19.74 with HTTP; Fri, 9 Nov 2012 10:55:37 -0800 (PST) In-Reply-To: References: <509BF0A2.2050600@digsys.bg> <393C72B3-7231-47C6-ABD2-1C6BA166ED11@gmail.com> <509CECA6.70308@digsys.bg> Date: Fri, 9 Nov 2012 13:55:37 -0500 Message-ID: Subject: Re: zfs remove vdev functionality From: Rich To: Johannes Totz Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-fs 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 18:55:39 -0000 I have not looked at the code to confirm this, but wouldn't the snapshots be built on the logical block addresses (e.g. the layer above the RAID/pool abstraction that maps to physical blocks) rather than physical block addresses? So as long as the logical block mapping is correct, the snapshot layer shouldn't care - it's if you were reshaping how the logical block layer being presented worked that would make this painful for that. Modulo the abstraction of translation that the DDT does, of course - I have no clue how that voodoo is implemented under the covers. - Rich On Fri, Nov 9, 2012 at 8:17 AM, Johannes Totz wrote: > 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" > > > > > _______________________________________________ > 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" >