Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

A curiosity related question:

Can a VDEV be removed from a ZFS pool by undoing the last pool transactions (zpool import -F) or rolling back to an earlier snapshot?

share|improve this question

closed as off-topic by ewwhite, Dave M, Scott Pack, kce, cole Nov 7 '13 at 0:53

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions must demonstrate a minimal understanding of the problem being solved. Try including attempted solutions, why they didn't work, and the expected results. See How can I ask better questions on Server Fault? for further guidance." – ewwhite, Dave M, Scott Pack, kce, cole
If this question can be reworded to fit the rules in the help center, please edit the question.

    
What's the situation here? What did you do? –  ewwhite Nov 2 '13 at 11:06
    
I didn't do anything. As mentioned this was merely curiosity. I was recently adding a vdev to a production pool, and while double checking the command wondered if there was a way it could be undone. BTW, it went just fine. –  Cyclone Nov 5 '13 at 4:43

2 Answers 2

up vote 1 down vote accepted

No. You're mistaking data and pool geography/layout. The former is transactional with some ability to go backwards (zpool import -F), the latter is not. Once you change it, it's changed. There's no rolling ring of previous pool layouts you can 'roll back' to.

share|improve this answer
    
Given the design of ZFS I would imagine rolling back to a snapshot when all the data was on one vdev, would mean that all the data would again be on that single vdev, including FS metadata, which means you could technically remove the new vdev without losing data. Now wether the tools would allow you to is another question. Anyways, I tested this out on a test pool and zpool import -F failed. –  Cyclone Nov 5 '13 at 4:48
    
By 'design of ZFS' I meant, my (mis)understanding that all the FS metadata is also treated just like regular data (checksumming, striping, etc.) –  Cyclone Nov 5 '13 at 5:04
    
Data about the topology of the pool is held in special labels on the leaf vdevs (disks) themselves at the front and end (double copies of each). These 4 entries are redundant copies, not different, and are only 256 KB each in length. They do not have information on history of the layout, merely the layout as it is "now". –  Nex7 Nov 8 '13 at 23:23
    
So technically you could remove the new vddv, forge the labels on the remaining vdevs, import the pool (with damaged data), and then rollback to the state when all the data was on the previous vdevs? –  Cyclone Nov 9 '13 at 15:56
1  
Technically? Yes, I suppose so. Much as, technically, I could suddenly have a radiation-induced genetic abnormality take over all my cells and cause me to sprout functional wings that would let me fly myself to the Bahamas. :) –  Nex7 Nov 9 '13 at 19:52

I am afraid you can not. That's a pitty. ZFS data is striped across available VDEVs and any hack will(may) result in data loss. Anyway you need to backup your data. So, backup and recreate your pool.

share|improve this answer
    
the pool is backed up and no mistake has been made. When I said 'curiosity' I meant it. It seems perfectly reasonable to wonder if such an action might work given the design of ZFS. Technically rolling back to a pre-new vdev mistake would return to all the data being on the original vdev.... we never got our BPR after all. –  Cyclone Nov 5 '13 at 4:54
    
It is pleasure to know that. I was not so lucky in the past when mistakenly added SSD drive as VDEV intended to be L2ARC. Now I check twice before typing. –  Veniamin Nov 8 '13 at 15:06

Not the answer you're looking for? Browse other questions tagged or ask your own question.