File:  [NetBSD Developer Wiki] / wikisrc / zfs.mdwn
Revision 1.35: download - view: text, annotated - select for diffs
Wed Feb 17 17:40:26 2021 UTC (23 months, 1 week ago) by gdt
Branches: MAIN
CVS tags: HEAD

    1: # ZFS on NetBSD
    3: This page attempts to do two things: provide enough orientation and
    4: pointers to standard ZFS documentation for NetBSD users who are new to
    5: ZFS, and to describe NetBSD-specific ZFS information.  It is
    6: emphatically not a tutorial or an introduction to ZFS.
    8: Many things are marked with \todo because they need a better
    9: explanation, and some have question marks
   11: # Documentation Pointers
   13: See the man pages for zfs(8), zpool(8).  Also see zdb(8), if only for
   14: seeing pool config info when run with no arguments.
   16:   - [OpenZFS Documentation](
   17:   - [OpenZFS admin docs index page](
   18:   - [FreeBSD Handbook ZFS Chapter](
   19:   - [Oracle ZFS Administration Manual](
   20:   - [Wikipedia](
   22: # Status of ZFS in NetBSD
   24: ## NetBSD 8
   26: NetBSD 8 has an old version of ZFS, and it is not recommended for use
   27: at all.  There is no evidence that anyone is interested in helping
   28: with ZFS on 8.  Those wishing to use ZFS on NetBSD 8 should therefore
   29: update to NetBSD 9.
   31: ## NetBSD 9
   33: NetBSD-9 has ZFS that is considered to work well.  There have been
   34: fixes since 9.0_RELEASE.  As always, people running NetBSD 9 are
   35: likely best served by the most recent version of the netbsd-9 stable
   36: branch.  As of 2021-02, ZFS in the NetBSD 9.1 release is very close to
   37: netbsd-9.
   39: ### Native blocksize
   41: ZFS attempts to find out the native blocksize for a disk when using it
   42: in a pool; this is almost always 512 or 4096.  Somewhere between 9.0
   43: and 9.1, at least some disks on some controllers that used to report
   44: 512 now report 4096.  This provokes a blocksize mismatch warning.
   46: Given that the native blocksize of the disk didn't change, and things
   47: seemed OK using the 512 emulated blocks, the warning is likely not
   48: critical.  However, it is also likely that rebuilding the pool with
   49: the 4096 blocksize is likely to result in better behavior because ZFS
   50: will only try to do 4096-byte writes.  \todo Verify this and find the
   51: actual change and explain better.
   53: ## NetBSD-current
   55: NetBSD-current (as of 2021-02) has similar ZFS code to 9.
   57: There is initial support for [[ZFS root|wiki/RootOnZFS]], via booting from
   58: ffs and pivoting.
   60: ## NetBSD/xen special issues
   62: In NetBSD-9, MAXPHYS is 64KB in most places, but because of xbd(4) it
   63: is set to 32KB for XEN kernels.  Thus the standard zfs kernel modules
   64: do not work under xen.  In NetBSD-current, xbd(4) supports 64 KB
   65: MAXPHYS and this is no longer an issue.
   67: Xen and zfs on current are reported to work well together, as of 2021-02.
   69: ## Architectures
   71: Most people seem to be using amd64.
   73: To build zfs, one puts MKZFS=yes in mk.conf.  This is default on amd64
   74: and aarch64 on netbsd-9.  In current, it is also default on sparc64.
   76: More or less, zfs can be enabled on an architecture when it is known
   77: to build and run reliably.  (Of course, users are welcome to build it
   78: and report.)
   80: # Quick Start
   82: See the [FreeBSD Quickstart
   83: Guide](; only
   84: the first item is NetBSD specific.
   86:   - Put zfs=YES in rc.conf.
   88:   - Create a pool as "zpool create pool1 /dev/dk0".
   90:   - df and see /pool1
   92:   - Create a filesystem mounted on /n0 as "zfs create -o
   93:     mountpoint=/n0 pool1/n0".
   95:   - Go back and read the documentation and start over.
   97: # NetBSD-specific information
   99: ## rc.conf
  101: The main configuration is to put zfs=YES in rc.conf, so that the rc.d
  102: scripts bring up ZFS and mount ZFS file systems.
  104: ## pool locations
  106: One can add disks or parts of disks into pools.  Methods of specifying
  107: areas to be included include:
  109:   - entire disks (e.g., /dev/wd0d on amd64, or /dev/wd0 which has the same major/minor)
  110:   - disklabel partitions (e.g., /dev/sd0e)
  111:   - wedges (e.g., /dev/dk0)
  113: Information about created or imported pools is stored in
  114: /etc/zfs/zpool.cache.
  116: ## pool importing problems
  118: While one can "zpool pool0 /dev/wd0f" and have a working pool, this
  119: pool cannot be exported and imported straigthforwardly.  "zpool
  120: export" works fine, and deletes zpool.cache.  "zpool import", however,
  121: only looks at entire disks (e.g. /dev/wd0), and might look at slices
  122: (e.g. /dev/dk0).  It does not look at partitions like /dev/wd0f, and
  123: there is no way on the command line to ask that specific devices be
  124: examined.  Thus, export/import fails for pools with disklabel
  125: partitions.
  127: One can make wd0 be a link to wd0f temporarily, and the pool will then
  128: be importable.  However, "wd0" is stored in zpool.cache and on the
  129: next boot that will attempt to be used.  This is obviously not a good
  130: approach.
  132: One an mkdir e.g. /etc/zfs/pool0 and in it have a symlink to
  133: /dev/wd0f.  Then, zpool import -d /etc/zfs/pool0 will scan
  134: /etc/zfs/pool0/wd0f and succeed.  The resulting zpool.cache will have
  135: that path, but having symlinks in /etc/zfs/POOLNAME seems acceptable.
  137: \todo Determine a good fix, perhaps man page changes only, fix it
  138: upstream, in curent, and in 9, before removing this discussion.
  140: ## mount order
  142: NetBSD 9 mounts other file systems and then ZFS file systems.  This can
  143: be a problem if /usr/pkgsrc is on ZFS and /usr/pkgsrc/distfiles is on
  144: NFS.  A workaround is to use noauto and do the mounts in
  145: /etc/rc.local.
  147: NetBSD current after 20200301 mounts ZFS first.  The same issues and
  148: workarounds apply in different circumstances.
  150: ## NFS
  152: zfs filesystems can be exported via NFS, simply by placing them in
  153: /etc/exports like any other filesystem.
  155: The "zfs share" command adds a line for each filesystem with the
  156: sharenfs property set to /etc/zfs/exports, and "zfs unshare" removes
  157: it.  This file is ignored on NetBSD-9 and current before 20210216; on
  158: current after 20210216 those filesystems should be exported (assuming
  159: NFS is enabled).  It does not appear to be possible to set options
  160: like maproot and network restrictions via this method.
  162: On current before 20210216, a remote mkdir of a filesystem mounted via
  163: -maproot=0:10 causes a kernel NULL pointer dereference.  This is now
  164: fixed.
  166: ## zvol
  168: Within a ZFS pool, the standard approach is to have file systems, but
  169: one can also create a zvol, which is a block device of a certain size.
  171: \todo The zvol will appear as /dev/???? and can be used in many
  172: respects like a slice.  However, the system will not read disklabels
  173: and gpt labels from a zvol; in this respect it is more like a disklabel
  174: partition or wedge than a disk drive.
  176: \todo Explain that one can export a zvol via iscsi.
  178: \todo Explain if one can swap on a zvol.
  180: \todo Explain that one can use ccd to create a normal-looking disk
  181: from a zvol.  This allows reading a GPT label from the zvol, which is
  182: useful in case the zvol had been exported via iscsi and some other
  183: system created a label.
  185: # Memory usage
  187: Basically, ZFS uses lots of memory and most people run it on systems
  188: with large amounts of memory.  NetBSD works well on systems with
  189: comparatively small amounts of memory.  So a natural question is how
  190: well ZFS works on one's VAX with 2M of RAM :-) More seriously, one
  191: might ask if it is reasonable to run ZFS on a RPI3 with 1G of RAM, or
  192: if it is reasonable on a system with 4G.
  194: The prevailing wisdom is more or less that ZFS consumes 1G plus 1G per
  195: 1T of disk.  32-bit architectures are viewed as too small to run ZFS.
  197: Besides RAM, zfs requires that architecture kernel stack size is at
  198: least 12KB or more -- some operations cause stack overflow with 8KB
  199: kernel stack. On NetBSD, the architectures with 16KB kernel stack are
  200: amd64, sparc64, powerpc, and experimental ia64, hppa. mac68k and sh3
  201: have 12KB kernel stack. All others use only 8KB stack, which is not
  202: enough to run zfs.
  204: NetBSD has many statistics provided via sysctl; see "sysctl
  205: kstat.zfs".
  207: FreeBSD has tunables that NetBSD does not seem to have, described in
  208: [FreeBSD Handbook ZFS Advanced
  209: section](
  211: # Interoperability with other systems
  213: Modern ZFS uses pool version 5000 and feature flags.
  215: It is in general possible to export a pool and them import the pool on
  216: some other system, as long as the other system supports all the used
  217: features.
  219: \todo Explain how to do this and what is known to work.
  221: \todo Explain feature flags relationship to FreeBSD, Linux, iIllumos,
  222: macOS.
  224: # Sources of ZFS code
  226: Currently, there are multiple ZFS projects and codebases:
  228:   - [OpenZFS](
  229:   - [openzfs repository](
  230:   - [zfsonlinux](
  231:   - [OpenZFS on OS X ]( [repo](
  232:   - proprietary ZFS in Solaris (not relevant in open source)
  233:   - ZFS as released under the CDDL (common ancestor, now of historical interest)
  235: OpenZFS is a coordinating project to align open ZFS codebases.  There
  236: is a notion of a shared core codebase and OS-specific adaptation code.
  238:   - [zfsonlinux relationship to OpenZFS](
  239:   - FreeBSD more or less imports code from openzfs and pushes back fixes. \todo Verify this.
  240:   - NetBSD has imported code from FreeBSD.
  241:   - The status of ZFS on macOS is unclear (2021-02).

CVSweb for NetBSD wikisrc <> software: FreeBSD-CVSweb