Date: Fri, 9 Nov 2012 13:55:37 -0500 From: Rich <rincebrain@gmail.com> To: Johannes Totz <johannes@jo-t.de> Cc: freebsd-fs <freebsd-fs@freebsd.org> Subject: Re: zfs remove vdev functionality Message-ID: <CAOeNLuqv6Um4PORfQD_EQPcsSmCrhmuB4Ni%2BVX%2BB1QQXSPJi4w@mail.gmail.com> In-Reply-To: <k7ivoi$ogo$1@ger.gmane.org> References: <509BF0A2.2050600@digsys.bg> <393C72B3-7231-47C6-ABD2-1C6BA166ED11@gmail.com> <509CECA6.70308@digsys.bg> <k7ivoi$ogo$1@ger.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@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@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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOeNLuqv6Um4PORfQD_EQPcsSmCrhmuB4Ni%2BVX%2BB1QQXSPJi4w>