zfs remove vdev functionality

Johannes Totz johannes at jo-t.de
Fri Nov 9 13:17:21 UTC 2012


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<daniel at 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.

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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
> 




More information about the freebsd-fs mailing list