Status update on v15 import
Martin Matuska
mm at FreeBSD.org
Thu Jul 8 10:51:48 UTC 2010
As for good news, I have fixed this as well.
Now it is:
Old kernel, old userland: OK (both zfs and zpool work)
Old kernel, new userland: OK (both zfs and zpool work)
New kernel, old userland: OK (both zfs and zpool work)
New kernel, new userland: OK (both zfs and zpool work)
The problem was that in v15 the check for internal private datasets was
moved out of userland to kernel.
So it was very easy to introduce a very simple compatibility fix and
check for "$" as the first character in appropriate userland parts, too.
The patch for the internal private datasets is here:
http://people.freebsd.org/~mm/patches/zfs/v15/head-v15-v3-compat.patch
(head-v15-v3.patch needs to be applied first)
Dňa 7. 7. 2010 16:33, M. Warner Losh wrote / napísal(a):
> In message: <4C3420AD.8040709 at FreeBSD.org>
> Martin Matuska <mm at FreeBSD.org> writes:
> : Hi all,
> :
> : I have some update on the status of the v15 upgrade:
> :
> : - crafted a new patch that follows steps of Solaris 10 going v15 (many
> : more revisions added)
> : - released a CFT on freebsd-current@, with very detailed patch
> : information including Solaris 10 patch numbers
> : - positive testing reports from running on i386, amd64 and sparc systems
> : (and cross-importing pools, etc.)
> : - the patch is now ready for head, I will commit it right after 8.1 gets
> : released
> : - an UPDATING entry will give notice about pool upgrading and that the
> : new utilities need a new kernel
> :
> : I have tested the binary compatibility with older utilities as well, and
> : it works properly, here is the matrix:
> :
> : Old kernel, old userland: OK
> : Old kernel, new userland: ERROR
> : New kernel, old userland: OK
> : New kernel, new userland: OK
> :
> : So this fullfills the import constraint into stable/8, I will tag the
> : commit with a 2-month MFC after:
>
> Actually, old kernel + new userland == ERROR does not necessarily
> fulfill the import constraints. What does ERROR mean here? For
> -current it might be alright (might here depends on what the
> consequences are). For -stable, the bar is much higher. Again, it
> might be OK, but what are the consequences of this error?
>
> While the project might not support totally arbitrary movements with
> kernel and userland, each case is judged based on the consequences of
> the errors.
>
> Warner
>
> : Link to the patch information file, including all imported revisions,
> : bug-ids and reference to Solairis 10 patch numbers:
> : http://people.freebsd.org/~mm/patches/zfs/v15/head-v15-v3.html
> : http://people.freebsd.org/~mm/patches/zfs/v15/head-v15-v3.txt
> :
> : Direct link to the patch:
> : http://people.freebsd.org/~mm/patches/zfs/v15/head-v15-v3.patch
> :
> : And I repeat: the patch applies cleanly against stable/8 as well (and
> : works).
> :
> : Cheers,
> : mm
> : _______________________________________________
> : zfs-devel at freebsd.org mailing list
> : http://lists.freebsd.org/mailman/listinfo/zfs-devel
> : To unsubscribe, send any mail to "zfs-devel-unsubscribe at freebsd.org"
> :
> :
> _______________________________________________
> zfs-devel at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/zfs-devel
> To unsubscribe, send any mail to "zfs-devel-unsubscribe at freebsd.org"
>
More information about the zfs-devel
mailing list