few ideas for zfsloader
fbsdlist at src.cx
Thu Apr 29 16:37:40 UTC 2010
Perhaps we can hijack vdev's boot block header and/or boot block
itself for these purposes. It's currently unused, according to ZFS
See chapters 1.3.2 and 1.4 in ZFS on-disk format:
On Thu, Apr 29, 2010 at 9:18 AM, Andriy Gapon <avg at freebsd.org> wrote:
> on 16/03/2010 21:07 Andriy Gapon said the following:
>> 2. Currently nextboot functionality doesn't work properly with ZFS because there
>> is no RW support in zfsloader. Adding that support seems to be quite hard given
>> the transactional nature of ZFS, checksums, compression and what not.
>> Here's an alternative idea: honor nextboot.conf only if boot filesystem has a a
>> special property set on it, for example org.freebsd:nextboot.
>> Then all we need is to flip the property off.
>> Although doing this is still not trivial it should be simpler than filesystem RW
> ZFS properties do, in fact, have the same nature as regular file data.
> So, changing a property value (whether filesystem or pool) requires practically
> the same level of write support as modification of a file.
> And this seems to be quite complex to do in loader; updating all necessary vdevs,
> doing checksums, transactions, etc.
> So, right now, I do not see a way to properly support nextboot with ZFS.
> We probably should emit some warning when nextboot.conf is created on ZFS that
> there will not be automatic recovery if kernel boot fails.
> Some really weird alternative ideas:
> 1. Write nextboot flag in some other place (NVRAM, special sectors of HDD)
> 2. Use time-limited nextboot - e.g. there is a timestamp in nextboot.conf and it
> is honored until the timestamp expires.
> But I won't seriously consider these.
> Andriy Gapon
> freebsd-fs at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
More information about the freebsd-fs