Disclaimer: I haven't used LUNs with ZFS, so take this with a grain of salt.
On Fri, Oct 26, 2012 at 4:08 PM, Morris Hooten <mhoo...@us.ibm.com> wrote:
> I'm creating a zpool that is 25TB in size.
> What are the recommendations in regards to LUN sizes?
The first standard advice I can give is that ZFS wants to be in charge of
the redundancy, otherwise it can only tell you when there is a data error,
but it can't fix it (other than possibly metadata copies, or if you set
copies for data). So, if you can have the LUNs be real disks, or otherwise
set up so that they reside on independent storage, something like a pool of
raidz2 vdevs, or of mirror pairs, is the general idea to provide good data
integrity. When ZFS detects data corruption, and it can't fix it (no
redundancy or problems in too many of the constituent sectors to
successfully reconstruct), it will return an I/O error, and not a "best
effort" at what it thinks the data was, so beware insufficient redundancy.
> For example:
> Should I have 4 x 6.25 TB LUNS to add to the zpool or 20 x 1.25TB LUNs to
> add to the pool?
> Or does it depend on the size of the san disks themselves?
Without redundancy controlled by ZFS, I am unsure whether having multiple
separate LUNs will change performance significantly, it probably depends
most upon whether the LUNs actually perform independently (if saturating
one doesn't make any other LUN significantly slower). When in doubt,
> Or should I divide the zpool up and make several smaller zpools?
Multiple storage zpools are not usually needed, one main point of ZFS is
that you can have as many filesystems as you want on each pool. As for
performance, zpool performance should, in theory, scale with the
performance of the underlying devices, so two small zpools shouldn't be
faster in aggregate than one large zpool.
The recommended configuration will depend on how you intend to use it, and
what your constraints are, which aren't clear.
zfs-discuss mailing list