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

Long ago, we bought an Adaptec 31605 under the impression that: a) it could do true JBOD, and b) it was well supported on OpenSolaris. Turns out both of these were incorrect. I'm trying to get my zpool onto a NexentaStor Enterprise OS, but to do that they want us to swap our controller out with a LSI SAS 9201-16i.

I'm trying to figure out the best way to cheaply migrate the pool. The current zpool uses about 1TB across 14 SAS drives. The best I can come up with is:

  1. offline system
  2. set up 3 1TB consumer-grade SATA drives as a temporary zpool on the on-board SATA ports
  3. zfs send all the data to the temporary pool
  4. swap controllers and build a new zpool on the LSI adapter
  5. zfs send from the temporary pool to the new zpool
  6. online system

Anything I'm missing here or thoughts of a better way to do it?

If I went this route how long should I expect the process to take? My rudimentary calculations tell me 1TB would take about 3 hours to transfer at 100MBps. Can I get that kind of throughput with a zfs send/recv on consumer-grade drives?

share|improve this question

3 Answers 3

up vote 1 down vote accepted

Your plan looks good, I imagine you won't have any trouble. You mentioned three 1TB disks for the temporary pool. I assume you'd planned to use single parity raidz (2TB usable), but I'd recommend you consider a mirrored pair of 1.5 or 2TB disks instead. This way when the migration is complete, each of the disks has a complete backup of your pool. Perfect for throwing in a safe deposit box in case of catastrophic failure. As for speed, I get 90-130MB/sec on a mirrored pool of two 2TB SATA disks, so your 3 Hours/TB figure (~100MB/sec) sounds reasonable. If you're paranoid like me, you may also want to scrub the temp pool before you reformat the SAS disks.

Once you switch to letting ZFS handle whole disks without a layer of controller abstraction the grass is truely greener. You can compare performance of multiple controllers with the same disks or even just attach the disks to a new system if hardware fails. I even temporarily imported a zfs pool into a VM under VMWare ESXi using raw device mapping, no nonsense it just worked.

share|improve this answer

IMHO in some situations this could be possible (not sure how different controllers handle the same disks):

  1. offline the system
  2. zpool export
  3. swap the controllers
  4. zpool import
  5. online system

Your proposal is anyway much safer because you always have two copies of your data until the end of migration.

Not sure if this can help you, but also consider the incremental zfs send.

  1. offline system
  2. set up 3 1TB consumer-grade SATA drives as a temporary zpool on the on-board SATA ports
  3. online system
  4. zfs send all the data to the temporary pool
  5. offline system
  6. zfs send -I all the differences to the temporary pool
  7. swap controllers and build a new zpool on the LSI adapter
  8. zfs send from the temporary pool to the new zpool
  9. online system

With this approach you can split the service downtime and let you do the first big and slow zfs send (SAS -> SATA) while the system is online.

share|improve this answer
    
The Adaptec isn't "true" JBOD, so there is some extra metadata that will prevent the drives from working as-is against a true JBOD. –  Sysadminicus Apr 14 '11 at 21:50

Your solutions sounds good. You can use the Auto Sync section of Nexenta if you prefer it over a manual ZFS send.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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