Date: Sat, 19 Feb 2011 03:32:43 -0500 From: grarpamp <grarpamp@gmail.com> To: freebsd-fs@freebsd.org Subject: [ZFS][PATCH] Read-only root file system prevents SPA Message-ID: <AANLkTi=t60iQDSh=K72QsymnPWGMan_8gBvZSV=CK7fE@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Justin, et al... >From a user perspective, sounds great! Always thought the cachefile was a pain. For example, some systems use encrypted pools, for which ZFS is rightly unaware of them until the cleartext devices are attached. ZFS SPA's attempts to manage it early in the process were annoying too. On lots of machines, the root fs (/) is read-only from power on. If a cache is desired, the cachefile parameter is set to either a tiny ufs state partition or mfs. Or /boot/zfs is mounted on the either of same via fstab. If not, cachefile=none :) zpool import -a still works regardless of the cache because it tastes all the devices, including CD-ROM's, heh. Works for me. With the configuration on disk as a design feature of ZFS, I'm not really sure of the need for a cachefile anyways. Other than maybe to limit tasting for a specific pool to select devices. Or having the kernel automagically do the zpool import -a (actually whatever subset of pools was in use previously) part for you on boot. BTW, there is no "zfs import" command. Nor is there a plain "zpool import" that does an import without further arguments. Though it does do the tasting and listing. And I'm not sure if, as with the un-writeable case, setting cachefile=none would also erroneously prevent needed events from occuring. If so, that should be fixed as well. Having vfs.zfs.ccw_retry_interval=0 meaning 'never update' would be fine.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTi=t60iQDSh=K72QsymnPWGMan_8gBvZSV=CK7fE>