I've got an existing Solaris ZFS NAS/SAN device and for a couple of reasons I'm looking to effectively destroy and re-create the zpool. The catch is that I don't have anywhere to put the data elsewhere, so it effectively has to stay on the box while I do this.

There's 12x1TB 7.2k SATA drives which make up the zpool in 6 mirrored pairs. My plan is as follows:

  1. In mirrored pair one, remove one of the drives from the pool completely.
  2. Create a new zpool containing only this drive
  3. Repeat (1) for each of the other mirrored pairs, adding them to the new zpool.
  4. By this point, I'm left with two zpools of the same size, with no redundancy, but containing 6 drives each.
  5. Copy the data over to the new pool and verify (with a scrub, I guess?)
  6. Once the data is copied, destroy the old pool, and add the 6 drives to the new pool as mirrors to the existing 6 drives.
  7. Ensure all the filesystems are correct and have the right attributes

Is there any reason why this wouldn't work? If not, is there a different/better way I could be doing this?


Why do you need to rebuild the pool? How much data is actually contained in the pool? That will have a greater effect on your migration strategy than anything else. If it is possible to place the data on a single disk (e.g. 1 or 2 Terabytes), I'd do that rather than risk a stripe of unmirrored disks. But again, it depends on how much data needs to move.

  • It's about 4TB of data. I need to rebuild to remove some pool attributes such as deduplication, which have been causing a few performance issues. I've been advised dedup in particular can only be purged from the pool by starting afresh. – growse Jun 19 '11 at 18:29
  • It sounds like you need more RAM or L2arc cache. What is the output of zpool status -D – ewwhite Jun 19 '11 at 18:33
  • Output in pastebin.com/bhpcRh6X - I never even knew about the -D switch giving the DDT size! I should mention - 30GB RAM in the server. Basically, Dedup isn't buying me much, but is costing me a lot, so I want to get rid. – growse Jun 19 '11 at 18:53
  • If this is really all about deduplication, first we'll need to know how you're storing data on the array. Are you serving NFS files? CIFS? iSCSI? Is this a backend for a VMWare environment? – ewwhite Jun 19 '11 at 19:09
  • It's a backend for a small VMware lab (NFS) as well as serving a couple of LUNs for a MSSQL cluster (iSCSI) and being a general fileserver for a small team (CIFS). I only enabled dedup to get the benefits for the CIFS share filesystem, but now have the situation where certain pool-heavy operations (deleting snapshots) has the effect of hanging the entire array. See related serverfault.com/questions/274394/… for my previous question on this. – growse Jun 19 '11 at 19:18

Your steps seems to amount to "leap frogging" the mirrors which are already in place. That will probably not "undo" the reduplication as those attributes will probably continue forward as the mirror sets rebuild. You may need to consider application-level replication/copying between the deduped vs. non-deduped pools in order to expand-out the actual file instances.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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