Date: Thu, 25 Jul 2013 21:48:03 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Andriy Gapon <avg@FreeBSD.org> Cc: freebsd-fs@FreeBSD.org, Glen Barber <gjb@FreeBSD.org>, FreeBSD Current <freebsd-current@FreeBSD.org> Subject: Re: r253070 and "disappearing" zpool Message-ID: <20130725194803.GA1400@garage.freebsd.pl> In-Reply-To: <51EFBEBF.601@FreeBSD.org> References: <20130710180548.GA2151@glenbarber.us> <51ECDF64.2020704@FreeBSD.org> <20130722203853.GB1400@garage.freebsd.pl> <51EFBEBF.601@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 24, 2013 at 02:47:11PM +0300, Andriy Gapon wrote: > on 22/07/2013 23:38 Pawel Jakub Dawidek said the following: > > The /boot/ has to be unencrypted and can be stored on eg. USB > > pendrive which is never left unattended, unlike laptop which can be left > > in eg. a hotel room, but with entire disk encrypted. >=20 > As we discussed elsewhere, there are many options of configuring full disk > encryption. Including decisions whether root filesystem should be separa= te from > boot filesystem, choice of filesystem type for boot fs, ways of tying var= ious > pieces together, and many more. >=20 > I do not believe that my change is incompatible with full disk encryption= in > general. Maybe you can imagine many ways of configuring it, but definiately the most typical one is to have separate /boot/ from /, where /boot/ is unencrypted and where you use one file system type for both (UFS or ZFS). > Let's also recall that the system was not created / configured by any of = the > existing official or semi-official tools and thus it does not represent a= ny > recommended way of setting up such systems. Glen configured it this way,= but it > doesn't mean that that is the way. Note that there are no official tools to install FreeBSD on ZFS. Is that enough reason to stop supporting it? What Glen did is the recommended way of setting up full disk encryption with ZFS. I'd do it the same way and I'd recommend this configuration to anyone who will (or did) ask me. > I think that there are many of ways of changing configuration of that sys= tem to > make behave as before again. > Three I mentioned already. Another is to add rc script to import the boo= t pool, > given that it is a special, designated pool. Yet another is to place > zpool.cache onto the root pool and use nullfs (instead of a symlink) to m= ake > /boot be from the boot pool but /boot/zfs be from the root pool. Come on... > > BTW. If moving zpool.cache to /etc/zfs/ will work for both cases that's > > fine by me, although the migration might be tricky. >=20 > Yes, that's migration that's scary to me too. >=20 >=20 > Now, about the postponed points. > I will reproduce a section from my email that you've snipped. >=20 > >> P.S. > >> ZFS/FreeBSD boot process is extremely flexible. For example zfsboot c= an take > >> zfsloader from pool1/fsA, zfsloader can boot kernel from pool2/fsB and= kernel > >> can mount / from pool3/fsC. Of these 3 filesystems from where should > >> zpool.cache be taken? > >> My firm opinion is that it should be taken from / (pool3/fsC in the ex= ample > >> above). Because it is the root filesystem that defines what a system = is going > >> to do ultimately: what daemons are started, with what configurations, = etc. > >> And thus it should also determine what pools to auto-import. > >> We can say that zpool.cache is analogous to /etc/fstab in this respect. >=20 > So do you or do you not agree with my reasoning about from where zpool.ca= che > should be taken? > If you do not, then please explain why. > If you do, then please explain how this would be compatible with the old = way of > loading zpool.cache. I don't have a strong opinion about this. As I said above I'm fine with moving zpool.cache to /etc/zfs/ if we can ensure it won't break existing installations. Still I'm not sure this was your initial goal, because you weren't aware of systems with separate boot pool until recently (if you were aware of this I hope you wouldn't commit the change without prior discussion). Which means in your eyes zpool.cache was always part of the root pool, because /boot/ was. > I think that ensuring that zpool.cache is always loaded from a root files= ystem > is the gain from my change. Were people complaining about zpool.cache being loaded from /boot/zfs/ and not from /etc/zfs/? I don't think so. But people do complain about boot pool not being autoimported. In my opinion for the end user it doesn't really matter if it is /etc/zfs/zpool.cache or /boot/zfs/zpool.cache, as both directories are available once the system is booted. For most people those two directories are placed on the same file system. For some people who actually care if this is /etc/zfs/ or /boot/zfs/, because those are separate file systems the latter works, the former doesn't. In my opinion the gain, if any, is only theoretical. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --XsQoSWH+UP9D9v3l Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlHxgPMACgkQForvXbEpPzReWQCgkMDxrjg0k3SuZ6aWKb4kIpiY IB8AoMwG4xOx8ncJX2KGtip2br8AtQjo =bkm1 -----END PGP SIGNATURE----- --XsQoSWH+UP9D9v3l--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130725194803.GA1400>