Date: Fri, 09 Nov 2012 13:44:38 +0200 From: Daniel Kalchev <daniel@digsys.bg> To: Nikolay Denev <ndenev@gmail.com> Cc: freebsd-fs@freebsd.org Subject: Re: zfs remove vdev functionality Message-ID: <509CECA6.70308@digsys.bg> In-Reply-To: <393C72B3-7231-47C6-ABD2-1C6BA166ED11@gmail.com> References: <509BF0A2.2050600@digsys.bg> <393C72B3-7231-47C6-ABD2-1C6BA166ED11@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 08.11.12 21:39, Nikolay Denev wrote: > On Nov 8, 2012, at 7:49 PM, Daniel Kalchev<daniel@digsys.bg> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?509CECA6.70308>