Skip site navigation (1)Skip section navigation (2)
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>