On 03/04/2016 12:50 AM, Richard Yao wrote: > On 03/02/2016 12:31 PM, Matthew Ahrens wrote: >> On Wed, Mar 2, 2016 at 12:37 AM, Erik Sørnes <[email protected]> wrote: >> >>> Hi! >>> >>> Are there any plans on implementing functionality to remove an entire vdev >>> from a pool ? >>> >>> One could write zpool remove <zpoolname> vdev <vdev-name>, and it would >>> move the data on <vdev-name> to other vdevs in the pool and then remove the >>> vdev <vdev-name> entirely. >>> This is very usefull for many use cases. I've googled a lot, and haven't >>> found any information on this, apart from a very old one from SUN. >>> >> >> Yes, we (Delphix) have implemented this and it is used in production. It >> is not yet upstreamed. For more info, see our talk at the 2014 OpenZFS >> Developer Summit: >> >> slides: >> http://open-zfs.org/w/images/b/b4/Device_Removal-Alex_Reece_%26_Matt_Ahrens.pdf >> video: >> http://www.youtube.com/watch?v=Xs6MsJ9kKKE&list=PLaUVvul17xSdOhJ-wDugoCAIPJZHloVoq&index=12 >> >> Here is the first commit for Device Removal from the Delphix repo (there >> are several follow on bug fixes and additional features): >> https://github.com/delphix/delphix-os/commit/db775effdda128d8e14216abde06281513b03c37 >> >> We haven't yet upstreamed this because it only supports removing >> non-redundant top-level vdevs (i.e. you can't remove a mirror or RAID-Z >> vdev). Additional work is needed to make sure that we don't lose any good >> copies of the data, and to ensure proper raid-z allocation alignment. We >> would welcome anyone who's interested in implementing these. >> >> We'd also appreciate opinions of "Please upstream even without >> mirror/RAID-Z support" or "Please don't integrate without mirror/RAID-Z >> support - all ZFS features should work together." > > My vote is for "Please don't integrate without mirror/RAID-Z > support - all ZFS features should work together."
I probably should elaborate on this. ZFS is intended to make administration simple. If we start introducing features that are unnecessarily incompatible with existing features, we risk a future where the non-interoperability of various features makes OpenZFS administration into a NP-complete boolean satisfiability problem. In addition, some ideas for features are far more incompatible with other things (e.g. killing checksums, redundancy, compression, etcetera for O_DIRECT support) have been discussed in private. If this is merged, the idea that "all ZFS features should work together" is not going to be a great argument against implementing even less compatible features. As useful as this is, I would rather that we not take the first step toward either scenario. > >> >> --matt >> >> >>> >>> kind regards >>> >>> Erik Sørnes, IT-support, Nilu >>> P Please consider the environment before printing this email and >>> attachments >>> >> >>
signature.asc
Description: OpenPGP digital signature
------------------------------------------- openzfs-developer Archives: https://www.listbox.com/member/archive/274414/=now RSS Feed: https://www.listbox.com/member/archive/rss/274414/28015062-cce53afa Modify Your Subscription: https://www.listbox.com/member/?member_id=28015062&id_secret=28015062-f966d51c Powered by Listbox: http://www.listbox.com
