Date: Tue, 16 Feb 2021 18:59:01 +0100 From: Lorenzo Perone <lopez.on.the.lists@yellowspace.net> To: freebsd-fs@freebsd.org Subject: Re: Migrating from base to OpenZFS: GELI drives, send/receive, and sysctls/loader.conf Message-ID: <3b13d100-92af-276c-dd58-3d914eeea432@yellowspace.net> In-Reply-To: <CAOjFWZ7UJH3kBeGBdT72sZEmyL_NdBr=X2bex35VSXb4fcTbLQ@mail.gmail.com> References: <183ed751-5a2e-5468-c82c-670820bac138@yellowspace.net> <CAOjFWZ7UJH3kBeGBdT72sZEmyL_NdBr=X2bex35VSXb4fcTbLQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 15.02.21 um 21:08 schrieb Freddie Cash: > On Mon., Feb. 15, 2021, 9:37 a.m. Lorenzo Perone, > <lopez.on.the.lists@yellowspace.net > <mailto:lopez.on.the.lists@yellowspace.net>> wrote: > > Hi All, > > I have followed regularly the development of openzfs for FreeBSD and I > guess I'm ready and eager to give it a first try on a 12.2 updated > system by using the port. > > Particularly watching the (now a little outdated, but still good) talk > by Alan Jude @ EuroBSDCon 2019 was very encouraging. > > What I'm planning as a first run is: > > On the same machine: > > - Boot with openzfs_load instead of zfs_load > - Import the "base" created pool with openzfs > - Create a new pool with openzfs > - Send/Receive and/or rsync data from the old to the new one > > > A few questions arised for which I didn't find an answer yet in the > official documentation. > > 1) Will a pool on GELI drives import well with openzfs too? I'd assume > yes, why shouldn't it. Just asking to correct me if there are any > precautions I should be taking or surprises to expect. > > 2) Will the "old" settings be honored by openzfs, such as > vfs.zfs.arc_min, vfs.zfs.arc_max in /boot/loader.conf? > > 3) Is there an openzfs_enable as opposed to zfs_enable in rc.conf (to > import/mount pools at boot)? Or is zfs_enable just compatible? > > 4) As far as I know, it should be possible to send/receive data from an > unencrypted dataset to an encrypted one. Is this advisable from an "old > base" zfs dataset (not encrypted, on geli) to a new openzfs one > (encrypted at the dataset level), or should we resort to rsync? > > 5) What's the actual current status on extended attributes? Will they be > retained in a send/receive from FreeBSD-"old" to FreeBSD-OpenZFS? I have > a few shares on that machine where macs have "dropped" their EAs via > AFP/SMB, what should I expect? > > Thanks a lot for any attention by people who know this right away, > > > If this is a boot pool, create a new boot environment and reboot into it > before making any changes. In the new BE, install the port, update > loader.conf and test things out. So long as you don't do a "zpool > upgrade" or enable any new features, then you can always change BE at > the loader menu to revert back to the working config. No, for boot SSDs I usually resort to UFS on gmirror + gjournal... ZFS on root is appealing (boot environments and rollbacks..) but until now booting has been something I have rather kept out of ZFS, legacy or not. Maybe one day.. :) > Doing it that way saved me a lot of headaches when trying to use the > openzfs packages (which don't work on 12.2). Had to eventually install > via the ports tree. Good to know. I'd expect something like this to be fixed soon, however? > A bunch of sysctls are the same, a bunch are named slightly differently, > and there's a whole bunch of new ones. Best bet is to comment then all > out and see if the autotune setup works for you. If not, then tweak the > new sysctls as you go. I'm usually totally fine with autotune, with the only exception of vfs.zfs.arc_min and vfs.zfs.arc_max... I'll dump them out once it starts working. > It's just zfs_enable in rc.conf for both base and port ZFS. Cool. > You can "zfs send" between versions without issue. Double cool :) > Can't help with the GELI or xattrs questions as I don't use those. I guess GELI is a no-brainer, xattrs I guess I'll find out.. Best Regards and thanx a lot!! Lorenzo
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3b13d100-92af-276c-dd58-3d914eeea432>