Honest mistake

[rs225]

What I mean by "in-place" is being able to convert a two-drive stripe to a mirror without losing the data on the stripe when one drive is removed.

I believe Matt Ahrens at Delphix is working on a feature that will 'work-around' the accidental stripe problem. I think it copies all the blocks on the accident to other vdevs, then inserts a permanent indirection internal to ZFS to remap that vdev, then removes the stripe vdev.

Sounds very reasonable, but it could be a while, since it is basically a big feature merely to handle a mistake that is probably better handled with extra UI in the GUI or cmd line.

 

[Arwen]

I believe Matt Ahrens at Delphix is working on a feature that will 'work-around' the accidental stripe problem. I think it copies all the blocks on the accident to other vdevs, then inserts a permanent indirection internal to ZFS to remap that vdev, then removes the stripe vdev.

Yes, that is my understanding as well.

Sounds very reasonable, but it could be a while, since it is basically a big feature merely to handle a mistake that is probably better handled with extra UI in the GUI or cmd line.

Again, yes. I think it likely won't show up in FreeNAS til the end of 2017 at the earliest.

The OpenZFS group had a video on the subject by Alex Reece. Here is a link;

https://www.youtube.com/watch?v=Xs6MsJ9kKKE

The overall method of using indirect pointers has problems, (and they are aware of them). First, they
require the pointers to remain in memory any time the pool in imported. Second, it only works for
striped or mirrored vDevs at present. If you want to remove a RAID-Zx vDev, it's currently not possible
with this method.

My own thoughts on vDev removal, involve:

1. Freezing writes to a vDev
2. Being able to list what files or zVols are on that vDev
3. Manually copying the files or zVols around, (thus automatically removing them from the vDev. See freezing writes in step 1.)
4. Whence the vDev is clear of all data, allow removal.

This method, (in the short term), does not require any low level data manipulation, like the block pointer
re-write. Later, steps 3 & 4 could be automated.

 

[rs225]

I think the reason Ahrens went that way is that it can be done without a full metadata tree scan and with only a single vdev freeze(otherwise known as UNAVAIL or FAULTED). My guess is it just reads the spacemaps of the removing vdev and copies those occupied blocks, then keeps the redirection table. For a fresh vdev, this is hopefully a short table.

The other way, you are doing a full metadata scan on a gigantic array, just to get a few blocks off one accidental drive, and you can't freeze the whole tree while it is running.