Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 29 Apr 2010 09:37:32 -0700
From:      Artem Belevich <fbsdlist@src.cx>
To:        Andriy Gapon <avg@freebsd.org>
Cc:        freebsd-fs@freebsd.org
Subject:   Re: few ideas for zfsloader
Message-ID:  <t2jed91d4a81004290937y1799630cp85be2a6515c1f921@mail.gmail.com>
In-Reply-To: <4BD9B16A.10606@freebsd.org>
References:  <4B9FD6E0.5000303@icyb.net.ua> <4BD9B16A.10606@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

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

--Artem



On Thu, Apr 29, 2010 at 9:18 AM, Andriy Gapon <avg@freebsd.org> wrote:
> on 16/03/2010 21:07 Andriy Gapon said the following:
>> 2. Currently nextboot functionality doesn't work properly with ZFS becau=
se there
>> is no RW support in zfsloader. =A0Adding 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 files=
ystem 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 pract=
ically
> the same level of write support as modification of a file.
>
> And this seems to be quite complex to do in loader; updating all necessar=
y 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@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?t2jed91d4a81004290937y1799630cp85be2a6515c1f921>