I am going to deploy an Ubuntu 12.04-based archiving system. Due to limitations of the SAN Storage, it can only present me with 2TB LUNs. So, I have to merge multiple 2TB LUNs to achieve the desired space (4.5TB with expected growth of up to 1TB per year).

The SAN Storage has its own RAID protection (yes, not a replacement for backup, I know), so I don't need a software-based RAID protection.

Please provide me suggestion on what should I use to 'combine' these LUNs:

  1. Combine them into a ZFS pool, or
  2. Combine them into an LVM VG

If possible, please also inform me of the drawback/benefit of both.

(All I can find on the Internet assume that the ZFS/LVM will be built on top of individual disks with RAID provided by RAIDZ/MDRAID, so really not suitable for my situation).

Note: Yeah, maybe I should use a better SAN Storage, but the 'Management' had decided to use this particular SAN Storage, and my hands are tied.

  • 1
    What do you want to achieve? What is your goal? For some scenarios ZFS is better for others not so much. – cstamas Jul 16 '13 at 14:13

Your choice would likely have twoish aspects:

  • data integrity and security
  • performance

When using different LUNs with ZFS, it will make implicit assumptions that the LUNs are separate physical devices, distributing reads and writes among them to optimize performance. You do not have to add more redundancy to the setup (i.e. you could just add your LUNs as simple vdevs) but it might interfere with your SAN array's optimization logics resulting in subpar performance.

Combining the LUNs in an LVM VG would just assign a part of the logical address space to each of the LUNs so the access characteristics would very much match the "single LUN" scenario unless you activate the striping mode.

ZFS' added data integrity features are not available with LVM or mdraid, so if you need them ZFS would be your only choice, regardless of the performance implications.

  • Thanks for the valuable input! Hmm, since this is for archiving purposes, I think "Data Integrity" trumps "Performance" anytime. Although I don't think I need ZFS' data integrity features per se, it's a very nice feature to guarantee data integrity, and ultimately defensible to the 'Management'. Thanks! – pepoluan Jul 16 '13 at 15:59
  • 2
    Careful. ZFS' data integrity features are merely unrecoverable errors if the configured zpool is a bunch of LUN's with no ZFS-configured redundancy (eg: mirroring of the LUN's, etc, within ZFS). ZFS will happily tell you (and block a request for) that a block is not matching its checksum and is thus bad -- but it will be unable to correct it if there's no parity (raidz) or other copy (mirror) to go snag (and since ZFS can't communicate with your back-end RAID device, there won't be, from ZFS's perspective). Also, as the responder says -- ZFS performance characteristics will bite you here, too. – Nex7 Jul 24 '13 at 17:30

A 2TB limit is not that uncommon, so you should stop thinking that you're being penalized more than most other setups in the world..

That being said - the most common way of doing this is to just stripe it (RAID 0) at the VM level. If you make sure that the SAN admin puts the LUNs on different controllers (if it's a active/active setup) you'll actually benefit from it, instead of having one big LUN on 1 controller.

It makes no difference if you use ZFS or built-in tools to do the striping, they all do it the same way.

  • Hehe, I'm just cutting off any "You should buy a better SAN Storage" answers before they appear :) – pepoluan Jul 16 '13 at 16:00

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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