-1

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?

Cyclone
  • 557
  • 5
  • 15
  • What's the situation here? What did you do? – ewwhite Nov 02 '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 05 '13 at 04:43

2 Answers2

1

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.

Veniamin
  • 863
  • 6
  • 11
  • 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 05 '13 at 04: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 08 '13 at 15:06
1

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.

Nex7
  • 1,995
  • 12
  • 14
  • 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 05 '13 at 04: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 05 '13 at 05: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 08 '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 09 '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 09 '13 at 19:52