[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Best practice for setting up disks for ZFS on NetBSD
hello David. In the absence of other variables, I'd suggest using
wedges. That gives you the ability to replace disks that go bad with
differently sized disks in the future, while still retaining your zfs vdev
sizes, something zfs likes a lot.
Also, I'm pretty sure zfs recovers fine from wedge renumbering, at
least it does under FreeBSD, much like raidframe does when it's
I should say that while I have a lot of experience with zfs under
FreeBSD, I've not used it much under NetBSD, mostly due to its instability,
which is apparently now becoming much less of a problem -- something I'm
very happy about.
Anyway, hope that helps.
On Dec 3, 12:30am, David Brownlee wrote:
} Subject: Best practice for setting up disks for ZFS on NetBSD
} What would be the best practice for setting up disks to use under ZFS
} on NetBSD, with particular reference to handling renumbered devices?
} The two obvious options seem to be:
} - Wedges, setup as a single large gpt partition of type zfs (eg /dev/dk7)
} - Entire disk (eg: /dev/wd0 or /dev/sd4)
} (I'm going to skip disklabel partitions as they are size limited and
} also encounter other issues with zpool import)
} Creating disks with single zfs wedges has the advantage of marking
} each disk as "hey, zfs in use here", so it should be less likely to
} accidentally overwrite it with something else, the wedge layer is
} light enough to not add any measurable overhead, and providing the zfs
} partition is aligned correctly zfs should be getting close enough to
} "the real disk"
} Using the entire disk seems simpler, and the system (including tools
} like iostat) are not suddenly cluttered by (in this case) a set of
} unnecessary dk entries.
} In the event of disk renumbering both are thrown out, needing a "zfs
} export foo;zfs import foo" to recover. Is there some way to avoid
>-- End of excerpt from David Brownlee
Main Index |
Thread Index |