ZFS Modifying filesystem structure

I will shortly be moving my system to a larger SSD. In the process I'd like to create a dataset /usr/local as a child of /user. This could make life easier if I have problems after upgrading packages and need to roll back.
My current structure is:
Code:
NAME                           USED  AVAIL  REFER  MOUNTPOINT
ssd/ROOT/fbsd12.2d            40.2G  74.9G  1.55G  /
ssd/ROOT/fbsd12.2d/usr        31.7G  74.9G  9.89G  /usr
ssd/ROOT/fbsd12.2d/usr/ports  8.84G  74.9G  6.72G  /usr/ports
ssd/ROOT/fbsd12.2d/usr/src    3.52G  74.9G  1.46G  /usr/src
ssd/ROOT/fbsd12.2d/var        6.67G  74.9G  1.63G  /var
ssd/ROOT/fbsd12.2d/var/db     3.21G  74.9G  1.93G  /var/db
ssd/ROOT/fbsd12.2d/var/empty   104K  74.9G    96K  /var/empty
ssd/ROOT/fbsd12.2d/var/tmp    1.03G  74.9G   136K  /var/tmp
I would like to create ssd/ROOT/fbsd12.2d/usr/local as a new dataset before using zfs send and zfs receive to copy the data.
My first thoughts are:
1) zfs create sdd/ROOT/fbsd12.2d/usr/dummy-local
2) rsync -a /usr/local/ /usr/dummy-local
3) zfs destroy /usr/local
4) zfs rename /usr/dummy-local /usr/local
I can see there's a risk if pulling the rug from under my feet in steps 3 & 4 unless I drop into single user mode, or switch to a different boot environment, and use some temporary mount points for ssd/ROOT/fbsd12.2d/usr and ssd/ROOT/fbsd12.2d/usr/local but is there a neater way of doing this by initially setting up an empty file system with the new structure on the destination drive before using zfs send and zfs receive?
 
  • When you're not using software in /usr/local (e.g. your shell) & you do that critical steps in single user mode, it should be fine. Alternatively you can only use utilities in base ( find -0|cpio -p0dmv or tar(1)), but that's a matter of taste. I'm not shure about how the various tools (rsync(1), cpdup(1), cpio(1), tar(1), pax(1), etc.pp.) handle extended attributes.
  • You can and should move /usr/ports, /usr/src & /var/tmp out of the ROOT. Please consult the Handbook for the default ZFS filesystem layout, there're good reasons to have the mentioned filesystems plus /usr/home, /var/crash, /var/cache, /var/log & /var/mail shared among BEs. Additionally, you can move many directories under /var/db (e.g. portsnap, since it's about the latest ports(7) tree branch and that's the same for all versions anyway) out of the root filesystem into their own, shared ZFS dataset. Remember that BE's don't run concurrently; i.e. many data can be shared. Also see this thread for an example. Note that some datasets like /usr& /var have set the canmount=off property, i.e. their purpose is to serve for their children to inherit the proper mountpoint. /var/mail usually is the only dataset that has atime=on. AFAIK /var/empty doesn't need it's own dataset -- it's empty...
 
  • When you're not using software in /usr/local (e.g. your shell) & you do that critical steps in single user mode, it should be fine. Alternatively you can only use utilities in base ( find -0|cpio -p0dmv or tar(1)), but that's a matter of taste. I'm not shure about how the various tools (rsync(1), cpdup(1), cpio(1), tar(1), pax(1), etc.pp.) handle extended attributes.
  • You can and should move /usr/ports, /usr/src & /var/tmp out of the ROOT. Please consult the Handbook for the default ZFS filesystem layout, there're good reasons to have the mentioned filesystems plus /usr/home, /var/crash, /var/cache, /var/log & /var/mail shared among BEs. Additionally, you can move many directories under /var/db (e.g. portsnap, since it's about the latest ports(7) tree branch and that's the same for all versions anyway) out of the root filesystem into their own, shared ZFS dataset. Remember that BE's don't run concurrently; i.e. many data can be shared. Also see this thread for an example. Note that some datasets like /usr& /var have set the canmount=off property, i.e. their purpose is to serve for their children to inherit the proper mountpoint. /var/mail usually is the only dataset that has atime=on. AFAIK /var/empty doesn't need it's own dataset -- it's empty...
I found tar to be quite convenient.

Your comments about moving some datasets outside the boot environment prompted me to review the entire structure of my pool which dates back nearly eight years to when I first started using ZFS and boot environments. At the time I erroneously based the structure of the pool on the previous UFS partitions plus some extra child datasets for which I applied different options. On reconsideration there's no real need for some of the child datasets and most of the contents of things like /usr and /var can be included in their parent dataset. I'm now in the process of totally restructuring my ZFS pool.

But I regard the default ZFS filesystem layout as being a suggestion rather than a hard and fast rule and for the way I use boot environments I feel that /usr/ports and, /usr/src need to be contained in the boot environment and not shared. On the other hand /usr/ports/distfiles can be shared
  • Occasionally I hit major dependency issues after a massive port upgrade session and it's much easier to switch back to the previous version instead of trying to sort out the problem so I need to have a port structure corresponding to the selected boot environment.
  • In due course when 13.0-RELEASE becomes available I'll be upgrading to it. Some packages, e.g. virtualbox-ose-kmod and drm-*-kmod need to have the kernel sources available while building. If /usr/src were outside the boot environment and I needed to revert back to 12.2-RELEASE I would be building against the wrong version.
.
[FONT=monospace][/FONT]
 
Back
Top