few ideas for zfsloader

[Andriy Gapon]

on 29/04/2010 19:37 Artem Belevich said the following:
> Perhaps we can hijack vdev's boot block header and/or boot block
> itself for these purposes. It's currently unused, according to ZFS
> spec.

I think that boot block is (can be) partially used by our zfsboot when a whole
disk is dedicated to ZFS (i.e. no partitioning).
E.g. see:
http://www.mail-archive.com/freebsd-stable@freebsd.org/msg103774.html

The idea is fine in general.  It's having to deal with multiple vdevs for a pool
with complex topology is what can get messy.  But I haven' given any real thought
to this yet.

If you come up with a design please share.
Thanks!

> See chapters 1.3.2 and 1.4 in ZFS on-disk format:
> http://hub.opensolaris.org/bin/download/Community+Group+zfs/docs/ondiskformat0822.pdf

Yep, have it on my (virtual) desk :-)

> 
> 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
>>> support.
>> 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
>> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
>> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
>>


-- 
Andriy Gapon