zfs remove vdev functionality

[Rich]

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 <johannes at jo-t.de> 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<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"
> >
>
>
> _______________________________________________
> 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"
>