Re: MFC of ZFSv15

2010-09-19 Thread Henri Hennebert
On 09/19/2010 18:33, Dan Mack wrote:
> But I should be able to boot my ZFSv14 root pool using the ZFSv15 build of 
> FreeBSD, correct? 

Yes
> But the problem scenario would be when I've upgraded by root pool to v15 and 
> I attempt to boot it with v14 boot loader.  At least that is what I think ...
You are right
> 
> I guess what I'm getting at is ... you should be able to buildworld, 
> installkernel, reboot, installworld, reboot without worry. 
It is the case

>  But when after your run 'zpool upgrade', you will need to re-write the 
> bootcode using gpart on each of your root pool ZFS disks.

I prefer to install bootcode BEFORE. Then reboot and check it with the
printf of my simple patch. Then you can zpool/zfs upgrade without problem.
> 
> Am I understanding this correctly ?
> 
> Thanks for all the work on ZFS BTW, it's great!
> 
> Dan
> 
> On Sep 16, 2010, at 2:03 PM, Henri Hennebert wrote:
> 
>> On 09/16/2010 17:18, jhell wrote:
>>> On 09/16/2010 09:55, Mike Tancsa wrote:

 Thanks again for all the ZFS fixes and enhancements!   Are there any
 caveats to upgrading ?

 Do I just do

 zpool upgrade -a
 zfs upgrade -a

 or are there any extra steps ?

>>>
>>> Hi Mike,
>>>
>>> No-one knows your bootcode better than you. So if you are upgrading
>>> don't forget if you are on a ZFS root then your bootcode might need
>>> updating.
>>>
>> I was bitten by this problem in a previous ZFS upgrade.
>>
>> To be sure, I have added this patch to zfsimpl.c so, at boot I know if 
>> zpool/zfs upgrade will be OK.
>>
>> Henri
>>>
>>> Regards, UPDATING should have anything else.
>>>
>>
>> ___
>> freebsd-stable@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
> 
> Dan
> --
> Dan Mack
> m...@macktronics.com
> 
> 
> 
> 
> 
> 

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: MFC of ZFSv15

2010-09-19 Thread Dan Mack
Thanks for the confirmation.  This worked fine and I did notice that "zpool 
upgrade zroot" was nice enough to emit the reminder:

  gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0

which is slightly different than the recipe given in /usr/src/UPDATING:

"gpart bootcode -p /boot/gptzfsboot -i 1 ad0"

Since the recipe for my root/zfs system included pmbr and gptzfsboot, I used 
the example emitted from the zpool command instead of the one from UPDATING.


e.g.

  pool: zroot
 state: ONLINE
status: The pool is formatted using an older on-disk format.  The pool can
still be used, but some features are unavailable.
action: Upgrade the pool using 'zpool upgrade'.  Once this is done, the
pool will no longer be accessible on older software versions.
 scrub: none requested
config:

NAME   STATE READ WRITE CKSUM
zroot  ONLINE   0 0 0
  mirror   ONLINE   0 0 0
gpt/disk0  ONLINE   0 0 0
gpt/disk1  ONLINE   0 0 0

errors: No known data errors

(zfs) ~ # zpool upgrade zroot
This system is currently running ZFS pool version 15.

Successfully upgraded 'zroot' from version 14 to version 15

If you boot from pool 'zroot', don't forget to update boot code.
Assuming you use GPT partitioning and da0 is your boot disk
the following command will do it:

gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0

(zfs) ~/zfs # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad4
ad4 has bootcode
(zfs) ~/zfs # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad5
ad5 has bootcode
(zfs) ~/zfs # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad6
ad6 has bootcode
(zfs) ~/zfs # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad7
ad7 has bootcode
(zfs) ~/zfs # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad8
ad8 has bootcode

(zfs) ~/zfs # reboot



Dan

On Sep 19, 2010, at 12:41 PM, Matthew Seaman wrote:

> On 19/09/2010 17:36:01, Dan Mack wrote:
>> But I should be able to boot my ZFSv14 root pool using the ZFSv15
>> build of FreeBSD, correct?   But the problem scenario would be when
>> I've upgraded my root pool to v15 and I attempt to boot it with v14
>> boot loader.  At least that is what I think ...
> 
> Yes.  The bootloader is not prescient, so  bootloader compiled against
> v14 can't cope with a zpool using v15.  It's only the on-disk format
> that counts in this: zfs software will operate perfectly well with older
> on-disk data formats.
> 
>> I guess what I'm getting at is ... you should be able to buildworld,
>> installkernel, reboot, installworld, reboot without worry.   But
>> after your run 'zpool upgrade', you will need to re-write the
>> bootcode using gpart on each of your root pool ZFS disks.
> 
> If you want to be completely paranoid, you could update the bootcode on
> your boot drive (or one out of a mirror pair, if that's what you're
> using) at the point of running installkernel and way before you run
> 'zpool upgrade'.  In theory, should this go horribly wrong and you end
> up with an unbootable system, you can recover by booting the 8.0 install
> media into FIXIT mode and reinstalling the bootblocks from there (or
> booting from the other disk in your mirror set).  Once you've got a
> system you know will reboot with the new bootblocks, then go ahead and
> with installworld and updating the zpool version.
> 
>> Am I understanding this correctly ?
> 
> Yep.  That's quite right.  Running 'zpool upgrade -a' is one of those
> operations you can't easily reverse, so designing an upgrade plan where
> you can stop and back-out at any point is quite tricky.  Fortunately,
> the risk of things going wrong at the point of running zpool upgrade is
> really very small, so for most purposes, just ploughing ahead and
> accepting the really very small risk is going to be acceptable.
> 
>   Cheers,
> 
>   Matthew
> 
> -- 
> Dr Matthew J Seaman MA, D.Phil.   7 Priory Courtyard
>  Flat 3
> PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
> JID: matt...@infracaninophile.co.uk   Kent, CT11 9PW
> 

Dan
--
Dan Mack
m...@macktronics.com




___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: MFC of ZFSv15

2010-09-19 Thread Matthew Seaman
On 19/09/2010 17:36:01, Dan Mack wrote:
> But I should be able to boot my ZFSv14 root pool using the ZFSv15
> build of FreeBSD, correct?   But the problem scenario would be when
> I've upgraded my root pool to v15 and I attempt to boot it with v14
> boot loader.  At least that is what I think ...

Yes.  The bootloader is not prescient, so  bootloader compiled against
v14 can't cope with a zpool using v15.  It's only the on-disk format
that counts in this: zfs software will operate perfectly well with older
on-disk data formats.

> I guess what I'm getting at is ... you should be able to buildworld,
> installkernel, reboot, installworld, reboot without worry.   But
> after your run 'zpool upgrade', you will need to re-write the
> bootcode using gpart on each of your root pool ZFS disks.

If you want to be completely paranoid, you could update the bootcode on
your boot drive (or one out of a mirror pair, if that's what you're
using) at the point of running installkernel and way before you run
'zpool upgrade'.  In theory, should this go horribly wrong and you end
up with an unbootable system, you can recover by booting the 8.0 install
media into FIXIT mode and reinstalling the bootblocks from there (or
booting from the other disk in your mirror set).  Once you've got a
system you know will reboot with the new bootblocks, then go ahead and
with installworld and updating the zpool version.

> Am I understanding this correctly ?

Yep.  That's quite right.  Running 'zpool upgrade -a' is one of those
operations you can't easily reverse, so designing an upgrade plan where
you can stop and back-out at any point is quite tricky.  Fortunately,
the risk of things going wrong at the point of running zpool upgrade is
really very small, so for most purposes, just ploughing ahead and
accepting the really very small risk is going to be acceptable.

Cheers,

Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.   7 Priory Courtyard
  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: matt...@infracaninophile.co.uk   Kent, CT11 9PW



signature.asc
Description: OpenPGP digital signature


Re: MFC of ZFSv15

2010-09-19 Thread Dan Mack
But I should be able to boot my ZFSv14 root pool using the ZFSv15 build of 
FreeBSD, correct?   But the problem scenario would be when I've upgraded by 
root pool to v15 and I attempt to boot it with v14 boot loader.  At least that 
is what I think ...

I guess what I'm getting at is ... you should be able to buildworld, 
installkernel, reboot, installworld, reboot without worry.   But when after 
your run 'zpool upgrade', you will need to re-write the bootcode using gpart on 
each of your root pool ZFS disks.

Am I understanding this correctly ?

Thanks for all the work on ZFS BTW, it's great!

Dan

On Sep 16, 2010, at 2:03 PM, Henri Hennebert wrote:

> On 09/16/2010 17:18, jhell wrote:
>> On 09/16/2010 09:55, Mike Tancsa wrote:
>>> 
>>> Thanks again for all the ZFS fixes and enhancements!   Are there any
>>> caveats to upgrading ?
>>> 
>>> Do I just do
>>> 
>>> zpool upgrade -a
>>> zfs upgrade -a
>>> 
>>> or are there any extra steps ?
>>> 
>> 
>> Hi Mike,
>> 
>> No-one knows your bootcode better than you. So if you are upgrading
>> don't forget if you are on a ZFS root then your bootcode might need
>> updating.
>> 
> I was bitten by this problem in a previous ZFS upgrade.
> 
> To be sure, I have added this patch to zfsimpl.c so, at boot I know if 
> zpool/zfs upgrade will be OK.
> 
> Henri
>> 
>> Regards, UPDATING should have anything else.
>> 
> 
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Dan
--
Dan Mack
m...@macktronics.com




___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: MFC of ZFSv15

2010-09-19 Thread Dan Mack

But I should be able to boot my ZFSv14 root pool using the ZFSv15 build of 
FreeBSD, correct?   But the problem scenario would be when I've upgraded my 
root pool to v15 and I attempt to boot it with v14 boot loader.  At least that 
is what I think ...

I guess what I'm getting at is ... you should be able to buildworld, 
installkernel, reboot, installworld, reboot without worry.   But after your run 
'zpool upgrade', you will need to re-write the bootcode using gpart on each of 
your root pool ZFS disks.

Am I understanding this correctly ?

Thanks for all the work on ZFS BTW, it's great!

Dan
On Sep 16, 2010, at 10:59 AM, Martin Matuska wrote:

> Dont forget to read the general "ZFS notes" section in UPDATING:
> 
> ZFS notes
> -
> When upgrading the boot ZFS pool to a new version, always follow
> these two steps:
> 
> 1.) recompile and reinstall the ZFS boot loader and boot block
> (this is part of "make buildworld" and "make installworld")
> 
> 2.) update the ZFS boot block on your boot drive
> 
> The following example updates the ZFS boot block on the first
> partition (freebsd-boot) of a GPT partitioned drive ad0:
> "gpart bootcode -p /boot/gptzfsboot -i 1 ad0"
> 
> Non-boot pools do not need these updates.
> 
> Dňa 16. 9. 2010 17:43, Mike Tancsa wrote / napísal(a):
>> At 11:18 AM 9/16/2010, jhell wrote:
>>> On 09/16/2010 09:55, Mike Tancsa wrote:
 
 Thanks again for all the ZFS fixes and enhancements! Are there any
 caveats to upgrading ?
 
 Do I just do
 
 zpool upgrade -a
 zfs upgrade -a
 
 or are there any extra steps ?
 
>>> 
>>> Hi Mike,
>>> 
>>> No-one knows your bootcode better than you. So if you are upgrading
>>> don't forget if you are on a ZFS root then your bootcode might need
>>> updating.
>> 
>> 
>> Hi,
>> I am booting off UFS right now so no bootcode updates for me :) I did
>> look at UPDATING which does mention
>> 
>> 20100915:
>> A new version of ZFS (version 15) has been merged.
>> This version uses a python library for the following subcommands:
>> zfs allow, zfs unallow, zfs groupspace, zfs userspace.
>> For full functionality of these commands the following port must
>> be installed: sysutils/py-zfs
>> 
>> ---Mike
>> 
>> 
>> 
>> Mike Tancsa, tel +1 519 651 3400
>> Sentex Communications, m...@sentex.net
>> Providing Internet since 1994 www.sentex.net
>> Cambridge, Ontario Canada www.sentex.net/mike
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Dan
--
Dan Mack
m...@macktronics.com




___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: MFC of ZFSv15

2010-09-17 Thread Paul Mather
On Sep 17, 2010, at 8:37 AM, Paul Mather wrote:

> On Sep 16, 2010, at 1:44 AM, Martin Matuska wrote:
> 
>> I have fixed the missing bits in r212688.
>> 
>> Thanks for the notice.
>> 
>> Dňa 15. 9. 2010 21:12, Xin LI  wrote / napísal(a):
>>> On 2010/09/15 11:30, Mike Tancsa wrote:
 At 02:07 PM 9/15/2010, Pascal Stumpf wrote:
> First of all, a great thanks to mm@ and pjd@ for the excellent work on
> ZFS in FreeBSD. :) And especially for the MFC of v15 a few hours ago.
>>> 
>>> [...]
 here too.  RELENG_8 AMD64.  The tinderboxes havent hit that branch yet
 (http://tinderbox.freebsd.org/), so it
 will be a few hrs before they get to test RELENG_8
>>> [...]
 -lsbuf  -lm -lnvpair -luutil -lutil
 /usr/obj/usr/src/tmp/usr/lib/libzfs.so: undefined reference to `getmntent'
 *** Error code 1
>>> 
>>> Sorry for that, it seems to be caused by a partial merge
>>> (cddl/compat/opensolaris/misc/mnttab.c).  mm@ is going to fix that ASAP.
>>> 
>>> Cheers,
> 
> I am getting a build failure on 8.1-STABLE:
> 
> =
> [[...]]
> cc -c -O2 -pipe -fno-strict-aliasing -march=pentium4 -std=c99  -Wall 
> -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
> -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
> -fformat-extensions -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq 
> -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
> -finline-limit=8000 --param inline-unit-growth=100 --param 
> large-function-growth=1000  -mno-align-long-strings 
> -mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse -mno-sse2 
> -mno-sse3 -ffreestanding -fstack-protector -Werror  
> /usr/src/sys/kern/p1003_1b.c
> cc -c -O2 -pipe -fno-strict-aliasing -march=pentium4 -std=c99  -Wall 
> -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
> -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
> -fformat-extensions -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq 
> -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
> -finline-limit=8000 --param inline-unit-growth=100 --param 
> large-function-growth=1000  -mno-align-long-strings 
> -mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse -mno-sse2 
> -mno-sse3 -ffreestanding -fstack-protector -Werror  
> /usr/src/sys/kern/posix4_mib.c
> cc -c -O2 -pipe -fno-strict-aliasing -march=pentium4 -std=c99  -Wall 
> -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
> -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
> -fformat-extensions -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq 
> -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
> -finline-limit=8000 --param inline-unit-growth=100 --param 
> large-function-growth=1000  -mno-align-long-strings 
> -mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse -mno-sse2 
> -mno-sse3 -ffreestanding -fstack-protector -Werror  
> /usr/src/sys/kern/sched_ule.c
> cc1: warnings being treated as errors
> /usr/src/sys/kern/sched_ule.c: In function 'sched_switch':
> /usr/src/sys/kern/sched_ule.c:1807: warning: implicit declaration of function 
> 'sched_pickcpu'
> /usr/src/sys/kern/sched_ule.c:1807: warning: nested extern declaration of 
> 'sched_pickcpu'
> *** Error code 1
> 
> Stop in /usr/obj/usr/src/sys/BACKUP.
> *** Error code 1
> 
> Stop in /usr/src.
> *** Error code 1
> 
> Stop in /usr/src.
> =
> 
> Unfortunately (for me, I guess), GENERIC will build successfully on this 
> system.  It's only my custom kernel config file that is failing "make 
> buildkernel."  The custom kernel config is GENERIC with various inapplicable 
> drivers removed, plus some non-GENERIC things added in (such as ALTQ support 
> options).  I am building via the standard "make buildworld" followed by "make 
> buildkernel" method.  Can anyone spot anything obviously awry?  I've included 
> my config file at the end.

Just to follow up myself, here: I added "options SMP" to my custom kernel 
config file and that allowed me successfully to finish "make buildkernel ..." 
without error.

So, is "options SMP" mandatory now on FreeBSD/i386 (even on uniprocessor 
systems), and, if so, shouldn't it be included in DEFAULTS?

Cheers,

Paul.

Re: MFC of ZFSv15

2010-09-17 Thread Jeremy Chadwick
On Fri, Sep 17, 2010 at 08:37:50AM -0400, Paul Mather wrote:
> On Sep 16, 2010, at 1:44 AM, Martin Matuska wrote:
> 
> > I have fixed the missing bits in r212688.
> > 
> > Thanks for the notice.
> > 
> > Dňa 15. 9. 2010 21:12, Xin LI  wrote / napísal(a):
> >> On 2010/09/15 11:30, Mike Tancsa wrote:
> >>> At 02:07 PM 9/15/2010, Pascal Stumpf wrote:
>  First of all, a great thanks to mm@ and pjd@ for the excellent work on
>  ZFS in FreeBSD. :) And especially for the MFC of v15 a few hours ago.
> >> 
> >> [...]
> >>> here too.  RELENG_8 AMD64.  The tinderboxes havent hit that branch yet
> >>> (http://tinderbox.freebsd.org/), so it
> >>> will be a few hrs before they get to test RELENG_8
> >> [...]
> >>> -lsbuf  -lm -lnvpair -luutil -lutil
> >>> /usr/obj/usr/src/tmp/usr/lib/libzfs.so: undefined reference to `getmntent'
> >>> *** Error code 1
> >> 
> >> Sorry for that, it seems to be caused by a partial merge
> >> (cddl/compat/opensolaris/misc/mnttab.c).  mm@ is going to fix that ASAP.
> >> 
> >> Cheers,
> 
> I am getting a build failure on 8.1-STABLE:
> 
> =
> [[...]]
> cc -c -O2 -pipe -fno-strict-aliasing -march=pentium4 -std=c99  -Wall 
> -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
> -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
> -fformat-extensions -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq 
> -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
> -finline-limit=8000 --param inline-unit-growth=100 --param 
> large-function-growth=1000  -mno-align-long-strings 
> -mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse -mno-sse2 
> -mno-sse3 -ffreestanding -fstack-protector -Werror  
> /usr/src/sys/kern/p1003_1b.c
> cc -c -O2 -pipe -fno-strict-aliasing -march=pentium4 -std=c99  -Wall 
> -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
> -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
> -fformat-extensions -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq 
> -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
> -finline-limit=8000 --param inline-unit-growth=100 --param 
> large-function-growth=1000  -mno-align-long-strings 
> -mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse -mno-sse2 
> -mno-sse3 -ffreestanding -fstack-protector -Werror  
> /usr/src/sys/kern/posix4_mib.c
> cc -c -O2 -pipe -fno-strict-aliasing -march=pentium4 -std=c99  -Wall 
> -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
> -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
> -fformat-extensions -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq 
> -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
> -finline-limit=8000 --param inline-unit-growth=100 --param 
> large-function-growth=1000  -mno-align-long-strings 
> -mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse -mno-sse2 
> -mno-sse3 -ffreestanding -fstack-protector -Werror  
> /usr/src/sys/kern/sched_ule.c
> cc1: warnings being treated as errors
> /usr/src/sys/kern/sched_ule.c: In function 'sched_switch':
> /usr/src/sys/kern/sched_ule.c:1807: warning: implicit declaration of function 
> 'sched_pickcpu'
> /usr/src/sys/kern/sched_ule.c:1807: warning: nested extern declaration of 
> 'sched_pickcpu'
> *** Error code 1


The problem was that a piece of committed code in the ULE scheduler was lacking
an #ifdef statement for checking "options SMP".  Meaning: kernel configs
which lacked "options SMP" would break exactly as shown above.

This has been fixed (see "Fix UP build" commit); please update your
source tree.

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/sched_ule.c

-- 
| Jeremy Chadwick   j...@parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator  Mountain View, CA, USA |
| Making life hard for others since 1977.  PGP: 4BD6C0CB |

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: MFC of ZFSv15

2010-09-17 Thread Paul Mather
On Sep 16, 2010, at 1:44 AM, Martin Matuska wrote:

> I have fixed the missing bits in r212688.
> 
> Thanks for the notice.
> 
> Dňa 15. 9. 2010 21:12, Xin LI  wrote / napísal(a):
>> On 2010/09/15 11:30, Mike Tancsa wrote:
>>> At 02:07 PM 9/15/2010, Pascal Stumpf wrote:
 First of all, a great thanks to mm@ and pjd@ for the excellent work on
 ZFS in FreeBSD. :) And especially for the MFC of v15 a few hours ago.
>> 
>> [...]
>>> here too.  RELENG_8 AMD64.  The tinderboxes havent hit that branch yet
>>> (http://tinderbox.freebsd.org/), so it
>>> will be a few hrs before they get to test RELENG_8
>> [...]
>>> -lsbuf  -lm -lnvpair -luutil -lutil
>>> /usr/obj/usr/src/tmp/usr/lib/libzfs.so: undefined reference to `getmntent'
>>> *** Error code 1
>> 
>> Sorry for that, it seems to be caused by a partial merge
>> (cddl/compat/opensolaris/misc/mnttab.c).  mm@ is going to fix that ASAP.
>> 
>> Cheers,

I am getting a build failure on 8.1-STABLE:

=
[[...]]
cc -c -O2 -pipe -fno-strict-aliasing -march=pentium4 -std=c99  -Wall 
-Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
-Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
-fformat-extensions -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
-finline-limit=8000 --param inline-unit-growth=100 --param 
large-function-growth=1000  -mno-align-long-strings 
-mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 
-ffreestanding -fstack-protector -Werror  /usr/src/sys/kern/p1003_1b.c
cc -c -O2 -pipe -fno-strict-aliasing -march=pentium4 -std=c99  -Wall 
-Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
-Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
-fformat-extensions -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
-finline-limit=8000 --param inline-unit-growth=100 --param 
large-function-growth=1000  -mno-align-long-strings 
-mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 
-ffreestanding -fstack-protector -Werror  /usr/src/sys/kern/posix4_mib.c
cc -c -O2 -pipe -fno-strict-aliasing -march=pentium4 -std=c99  -Wall 
-Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
-Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign 
-fformat-extensions -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq 
-D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
-finline-limit=8000 --param inline-unit-growth=100 --param 
large-function-growth=1000  -mno-align-long-strings 
-mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 
-ffreestanding -fstack-protector -Werror  /usr/src/sys/kern/sched_ule.c
cc1: warnings being treated as errors
/usr/src/sys/kern/sched_ule.c: In function 'sched_switch':
/usr/src/sys/kern/sched_ule.c:1807: warning: implicit declaration of function 
'sched_pickcpu'
/usr/src/sys/kern/sched_ule.c:1807: warning: nested extern declaration of 
'sched_pickcpu'
*** Error code 1

Stop in /usr/obj/usr/src/sys/BACKUP.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
=

Unfortunately (for me, I guess), GENERIC will build successfully on this 
system.  It's only my custom kernel config file that is failing "make 
buildkernel."  The custom kernel config is GENERIC with various inapplicable 
drivers removed, plus some non-GENERIC things added in (such as ALTQ support 
options).  I am building via the standard "make buildworld" followed by "make 
buildkernel" method.  Can anyone spot anything obviously awry?  I've included 
my config file at the end.

Cheers,

Paul.

#
# GENERIC -- Generic kernel configuration file for FreeBSD/i386
#
# For more information on this file, please read the handbook section on
# Kernel Configuration Files:
#
#
http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html
#
# The handbook is also available locally in /usr/share/doc/handbook
# if you've installed the doc distribution, otherwise always see the
# FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the
# latest information.
#
# An exhaustive list of options and more detailed explanations of the
# device lines is also present in the ../../conf/NOTES and NOTES files.
# If you are in doubt as to the purpose or necessity of a line, check first
# in NOTES.
#
# $FreeBSD: src/sys/i386/conf/GENERIC,v 1.474.2.19 2009/07/15 08:32:19 ed Exp $

cpu I586_CPU
cpu I686_CPU
ident   BACKUP

# To statically compile in device wiring instead of /boot/device.hints
#hints  "GENERIC.hints" # Default places to look for devices.

#makeoptionsDEBUG=-g# Build kernel with gdb(1) debug symbols

#optionsSCHED_4BSD  # 4BSD scheduler
options 

Re: MFC of ZFSv15

2010-09-16 Thread Henri Hennebert

On 09/16/2010 17:18, jhell wrote:

On 09/16/2010 09:55, Mike Tancsa wrote:


Thanks again for all the ZFS fixes and enhancements!   Are there any
caveats to upgrading ?

Do I just do

zpool upgrade -a
zfs upgrade -a

or are there any extra steps ?



Hi Mike,

No-one knows your bootcode better than you. So if you are upgrading
don't forget if you are on a ZFS root then your bootcode might need
updating.


I was bitten by this problem in a previous ZFS upgrade.

To be sure, I have added this patch to zfsimpl.c so, at boot I know if 
zpool/zfs upgrade will be OK.


Henri


Regards, UPDATING should have anything else.



Index: sys/boot/zfs/zfsimpl.c
===
--- sys/boot/zfs/zfsimpl.c  (revision 212549)
+++ sys/boot/zfs/zfsimpl.c  (working copy)
@@ -61,6 +61,8 @@
STAILQ_INIT(&zfs_vdevs);
STAILQ_INIT(&zfs_pools);
 
+   printf("ZFS: supported version %u\n", (unsigned) SPA_VERSION);
+
zfs_temp_buf = malloc(TEMP_SIZE);
zfs_temp_end = zfs_temp_buf + TEMP_SIZE;
zfs_temp_ptr = zfs_temp_buf;
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: MFC of ZFSv15

2010-09-16 Thread Martin Matuska
 Dont forget to read the general "ZFS notes" section in UPDATING:

ZFS notes
-
When upgrading the boot ZFS pool to a new version, always follow
these two steps:

1.) recompile and reinstall the ZFS boot loader and boot block
(this is part of "make buildworld" and "make installworld")

2.) update the ZFS boot block on your boot drive

The following example updates the ZFS boot block on the first
partition (freebsd-boot) of a GPT partitioned drive ad0:
"gpart bootcode -p /boot/gptzfsboot -i 1 ad0"

Non-boot pools do not need these updates.

Dňa 16. 9. 2010 17:43, Mike Tancsa wrote / napísal(a):
> At 11:18 AM 9/16/2010, jhell wrote:
>> On 09/16/2010 09:55, Mike Tancsa wrote:
>> >
>> > Thanks again for all the ZFS fixes and enhancements! Are there any
>> > caveats to upgrading ?
>> >
>> > Do I just do
>> >
>> > zpool upgrade -a
>> > zfs upgrade -a
>> >
>> > or are there any extra steps ?
>> >
>>
>> Hi Mike,
>>
>> No-one knows your bootcode better than you. So if you are upgrading
>> don't forget if you are on a ZFS root then your bootcode might need
>> updating.
>
>
> Hi,
> I am booting off UFS right now so no bootcode updates for me :) I did
> look at UPDATING which does mention
>
> 20100915:
> A new version of ZFS (version 15) has been merged.
> This version uses a python library for the following subcommands:
> zfs allow, zfs unallow, zfs groupspace, zfs userspace.
> For full functionality of these commands the following port must
> be installed: sysutils/py-zfs
>
> ---Mike
>
>
> 
> Mike Tancsa, tel +1 519 651 3400
> Sentex Communications, m...@sentex.net
> Providing Internet since 1994 www.sentex.net
> Cambridge, Ontario Canada www.sentex.net/mike
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: MFC of ZFSv15

2010-09-16 Thread Mike Tancsa

At 11:18 AM 9/16/2010, jhell wrote:

On 09/16/2010 09:55, Mike Tancsa wrote:
>
> Thanks again for all the ZFS fixes and enhancements!   Are there any
> caveats to upgrading ?
>
> Do I just do
>
> zpool upgrade -a
> zfs upgrade -a
>
> or are there any extra steps ?
>

Hi Mike,

No-one knows your bootcode better than you. So if you are upgrading
don't forget if you are on a ZFS root then your bootcode might need
updating.



Hi,
I am booting off UFS right now so no bootcode updates for me 
:)  I did look at UPDATING which does mention


20100915:
A new version of ZFS (version 15) has been merged.
This version uses a python library for the following subcommands:
zfs allow, zfs unallow, zfs groupspace, zfs userspace.
For full functionality of these commands the following port must
be installed: sysutils/py-zfs

---Mike



Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,m...@sentex.net
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: MFC of ZFSv15

2010-09-16 Thread jhell
On 09/16/2010 09:55, Mike Tancsa wrote:
> 
> Thanks again for all the ZFS fixes and enhancements!   Are there any
> caveats to upgrading ?
> 
> Do I just do
> 
> zpool upgrade -a
> zfs upgrade -a
> 
> or are there any extra steps ?
> 

Hi Mike,

No-one knows your bootcode better than you. So if you are upgrading
don't forget if you are on a ZFS root then your bootcode might need
updating.


Regards, UPDATING should have anything else.

-- 

 jhell,v
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: MFC of ZFSv15

2010-09-16 Thread Mike Tancsa


Thanks again for all the ZFS fixes and enhancements!   Are there any 
caveats to upgrading ?


Do I just do

zpool upgrade -a
zfs upgrade -a

or are there any extra steps ?

---Mike






Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,m...@sentex.net
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: MFC of ZFSv15

2010-09-16 Thread Marian Hettwer
On Thu, 16 Sep 2010 12:42:36 +0200, Guido Falsi 
wrote:
> On Thu, Sep 16, 2010 at 10:53:02AM +0100, Marian Hettwer wrote:
>> On Thu, 16 Sep 2010 10:42:40 +0200, Guido Falsi 
>> wrote:
>> > On Thu, Sep 16, 2010 at 07:44:31AM +0200, Martin Matuska wrote:
>> >> I have fixed the missing bits in r212688.
>> >>
>> >> Thanks for the notice.
>> >
>> > Just a thank you message for the v15 development, MFS and this fast
>> > fix. Maybe this is just noise on the lists, but I think that too
>> > little thanks get to the FreeBSD developers, so a little noise like
>> > this may be beneficial.
>>
>> Agreed to that! Thanks for all the efforts in bringing ZFS to FreeBSD.
>> I'm running 8.1-Release with v15 without any problems.
>>
>> I just copied a 21GB MySQL datadir from a linux box to my FreeBSD/zfs
>> workstation. Thanks to zfs compression the 21GB only consume 10GB on
>> zfs.
>> That's massive compression :-)
> 
> Related to this, I have a question.
>
Related, but on its way to get off topic...
 
> Is it convenient to put databases on a compresed filesystem? Apart from
> the space advantage, does it give any speed advantage/penalty?
>
At work we use Solaris 10 with zfs and compression enabled for our
MySQL databases.
All InnoDB. No speed penalty and only really slight advantages. I tend
to say, it doesn't matter.
It gives you more disk space by a wee bit of more CPU consumption.
On the other hand, CPU is usually not your problem in a heavy load
MySQL scenario.
It's disc seek times...
 
> Anyone has some benchmark or objective data about this?
>
No benchmarks and no time right now to come up with some fancy graphs.
 
> Also are we talking about MyISAM or InnoDB tables? Or a mix of those?
InnoDB.

./Marian
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: MFC of ZFSv15

2010-09-16 Thread Ivan Voras

On 09/16/10 12:42, Guido Falsi wrote:


Related to this, I have a question.

Is it convenient to put databases on a compresed filesystem? Apart from
the space advantage, does it give any speed advantage/penalty?


It depends on what you do. It will not save you memory usage either 
since data needs to be decompressed when read.


If the database is lightly loaded I don't think there will ever be 
problems. Also if the database is mostly read-only. If it's used in a 
heavy loaded read+write environment or if it is CPU-bound, it is 
probably a bad idea to put it on a compressed file system.



Anyone has some benchmark or objective data about this?


I know about this one:

http://don.blogs.smugmug.com/2008/10/13/zfs-mysqlinnodb-compression-update/

But it only really measures copy (cp) speeds and compression, not 
database performance.



Also are we talking about MyISAM or InnoDB tables? Or a mix of those?


MyISAM would probably be faster to compress and manage :)

http://www.scribd.com/doc/14603831/Optimizing-MySQL-Performance-with-ZFS

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: MFC of ZFSv15

2010-09-16 Thread Guido Falsi
On Thu, Sep 16, 2010 at 10:53:02AM +0100, Marian Hettwer wrote:
> On Thu, 16 Sep 2010 10:42:40 +0200, Guido Falsi 
> wrote:
> > On Thu, Sep 16, 2010 at 07:44:31AM +0200, Martin Matuska wrote:
> >> I have fixed the missing bits in r212688.
> >>
> >> Thanks for the notice.
> > 
> > Just a thank you message for the v15 development, MFS and this fast
> > fix. Maybe this is just noise on the lists, but I think that too
> > little thanks get to the FreeBSD developers, so a little noise like
> > this may be beneficial.
> 
> Agreed to that! Thanks for all the efforts in bringing ZFS to FreeBSD.
> I'm running 8.1-Release with v15 without any problems.
> 
> I just copied a 21GB MySQL datadir from a linux box to my FreeBSD/zfs
> workstation. Thanks to zfs compression the 21GB only consume 10GB on
> zfs.
> That's massive compression :-)

Related to this, I have a question.

Is it convenient to put databases on a compresed filesystem? Apart from
the space advantage, does it give any speed advantage/penalty?

Anyone has some benchmark or objective data about this?

Also are we talking about MyISAM or InnoDB tables? Or a mix of those?

-- 
Guido Falsi 
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: MFC of ZFSv15

2010-09-16 Thread Marian Hettwer
On Thu, 16 Sep 2010 10:42:40 +0200, Guido Falsi 
wrote:
> On Thu, Sep 16, 2010 at 07:44:31AM +0200, Martin Matuska wrote:
>> I have fixed the missing bits in r212688.
>>
>> Thanks for the notice.
> 
> Just a thank you message for the v15 development, MFS and this fast
> fix. Maybe this is just noise on the lists, but I think that too
> little thanks get to the FreeBSD developers, so a little noise like
> this may be beneficial.

Agreed to that! Thanks for all the efforts in bringing ZFS to FreeBSD.
I'm running 8.1-Release with v15 without any problems.

I just copied a 21GB MySQL datadir from a linux box to my FreeBSD/zfs
workstation. Thanks to zfs compression the 21GB only consume 10GB on
zfs.
That's massive compression :-)

So again: Thanks to all developers and keep up the good work!

./Marian
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: MFC of ZFSv15

2010-09-16 Thread Guido Falsi
On Thu, Sep 16, 2010 at 07:44:31AM +0200, Martin Matuska wrote:
> I have fixed the missing bits in r212688.
> 
> Thanks for the notice.

Just a thank you message for the v15 development, MFS and this fast
fix. Maybe this is just noise on the lists, but I think that too
little thanks get to the FreeBSD developers, so a little noise like
this may be beneficial.

-- 
Guido Falsi 
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: MFC of ZFSv15

2010-09-15 Thread Martin Matuska
I have fixed the missing bits in r212688.

Thanks for the notice.

Dňa 15. 9. 2010 21:12, Xin LI  wrote / napísal(a):
> On 2010/09/15 11:30, Mike Tancsa wrote:
>> At 02:07 PM 9/15/2010, Pascal Stumpf wrote:
>>> First of all, a great thanks to mm@ and pjd@ for the excellent work on
>>> ZFS in FreeBSD. :) And especially for the MFC of v15 a few hours ago.
> 
> [...]
>> here too.  RELENG_8 AMD64.  The tinderboxes havent hit that branch yet
>> (http://tinderbox.freebsd.org/), so it
>> will be a few hrs before they get to test RELENG_8
> [...]
>> -lsbuf  -lm -lnvpair -luutil -lutil
>> /usr/obj/usr/src/tmp/usr/lib/libzfs.so: undefined reference to `getmntent'
>> *** Error code 1
> 
> Sorry for that, it seems to be caused by a partial merge
> (cddl/compat/opensolaris/misc/mnttab.c).  mm@ is going to fix that ASAP.
> 
> Cheers,
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: MFC of ZFSv15

2010-09-15 Thread Chip Camden
Quoth Pascal Stumpf on Wednesday, 15 September 2010:
> First of all, a great thanks to mm@ and pjd@ for the excellent work on 
> ZFS in FreeBSD. :) And especially for the MFC of v15 a few hours ago.
> 
> Unfortunately, buildworld currently fails (8-STABLE amd64) when linking 
> libzfs with an »undefined reference to getmntent« error. Can anyone else 
> confirm?
> 
> Cheers,
> Pascal
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Same here.  8-STABLE amd64, same error.

-- 
Sterling (Chip) Camden| sterl...@camdensoftware.com | 2048D/3A978E4F
http://camdensoftware.com | http://chipstips.com| http://chipsquips.com


pgpsbTC1PbgPh.pgp
Description: PGP signature


Re: MFC of ZFSv15

2010-09-15 Thread Xin LI
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2010/09/15 11:30, Mike Tancsa wrote:
> At 02:07 PM 9/15/2010, Pascal Stumpf wrote:
>> First of all, a great thanks to mm@ and pjd@ for the excellent work on
>> ZFS in FreeBSD. :) And especially for the MFC of v15 a few hours ago.
> 
[...]
> here too.  RELENG_8 AMD64.  The tinderboxes havent hit that branch yet
> (http://tinderbox.freebsd.org/), so it
> will be a few hrs before they get to test RELENG_8
[...]
> -lsbuf  -lm -lnvpair -luutil -lutil
> /usr/obj/usr/src/tmp/usr/lib/libzfs.so: undefined reference to `getmntent'
> *** Error code 1

Sorry for that, it seems to be caused by a partial merge
(cddl/compat/opensolaris/misc/mnttab.c).  mm@ is going to fix that ASAP.

Cheers,
- -- 
Xin LI http://www.delphij.net/
FreeBSD - The Power to Serve!  Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)

iQEcBAEBCAAGBQJMkRqwAAoJEATO+BI/yjfBUlEH/0oEST4976dZ4TKdawx8OWdJ
X81gQvH0rl29xS+pJkuELMGROgsFDp3bCsYREFItAOYYAk4hDWRCqghXH2TzpcgJ
N1VHjfe/nnZzvoJ1XTPuUcPH2F6okg7hfgb7zGHc120x/xDKOyW8urNEOrPKT/P4
edsyD/Ilp0S97GiVW6LjCmY05ieTS/IqnjMSFSPiWN9DkkcdccQfDRQL5v71RgBF
nCHwsqgEZjAsdtebmdAoFBtAR9Hm3+N7W6AhCMfM/mLF2xHzD1BxWPO1vQ+k1Mfx
huMVRlsZ4PK5JIqUNYzfUzGZqNfCcdafBbw0BsnPf/n7kMWXQVNCFM8iaFXPWUQ=
=EncA
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: MFC of ZFSv15

2010-09-15 Thread Mike Tancsa

At 02:07 PM 9/15/2010, Pascal Stumpf wrote:

First of all, a great thanks to mm@ and pjd@ for the excellent work on
ZFS in FreeBSD. :) And especially for the MFC of v15 a few hours ago.


Yes, thats a LOT of fixes!  Some look very interesting indeed :)

  8632:36ef517870a3
  6798384 It can take a village to raise a zio (141445-01)



Unfortunately, buildworld currently fails (8-STABLE amd64) when linking
libzfs with an »undefined reference to getmntent« error. Can anyone else
confirm?



here too.  RELENG_8 AMD64.  The tinderboxes 
havent hit that branch yet 
(http://tinderbox.freebsd.org/), 
so it will be a few hrs before they get to test RELENG_8

===> cddl/sbin/zfs (all)
cc -O2 
-pipe 
-I/usr/src/cddl/sbin/zfs/../../../cddl/contrib/opensolaris/lib/libzpool/common 
-I/usr/src/cddl/sbin/zfs/../../../cddl/compat/opensolaris/include 
-I/usr/src/cddl/sbin/zfs/../../../cddl/compat/opensolaris/lib/libumem 
-I/usr/src/cddl/sbin/zfs/../../../sys/cddl/compat/opensolaris 
-I/usr/src/cddl/sbin/zfs/../../../cddl/contrib/opensolaris/head 
-I/usr/src/cddl/sbin/zfs/../../../cddl/contrib/opensolaris/lib/libuutil/common 
-I/usr/src/cddl/sbin/zfs/../../../cddl/contrib/opensolaris/lib/libzfs/common 
-I/usr/src/cddl/sbin/zfs/../../../cddl/contrib/opensolaris/lib/libumem/common 
-I/usr/src/cddl/sbin/zfs/../../../cddl/contrib/opensolaris/lib/libnvpair 
-I/usr/src/cddl/sbin/zfs/../../../sys/cddl/contrib/opensolaris/uts/common 
-I/usr/src/cddl/sbin/zfs/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs 
-I/usr/src/cddl/sbin/zfs/../../../sys/cddl/contrib/opensolaris/uts/common/sys 
-DNEED_SOLARIS_BOOLEAN -std=gnu89 
-fstack-protector -Wno-unknown-pragmas -c 
/usr/src/cddl/sbin/zfs/../../../cddl/contrib/opensolaris/cmd/zfs/zfs_main.c
cc -O2 
-pipe 
-I/usr/src/cddl/sbin/zfs/../../../cddl/contrib/opensolaris/lib/libzpool/common 
-I/usr/src/cddl/sbin/zfs/../../../cddl/compat/opensolaris/include 
-I/usr/src/cddl/sbin/zfs/../../../cddl/compat/opensolaris/lib/libumem 
-I/usr/src/cddl/sbin/zfs/../../../sys/cddl/compat/opensolaris 
-I/usr/src/cddl/sbin/zfs/../../../cddl/contrib/opensolaris/head 
-I/usr/src/cddl/sbin/zfs/../../../cddl/contrib/opensolaris/lib/libuutil/common 
-I/usr/src/cddl/sbin/zfs/../../../cddl/contrib/opensolaris/lib/libzfs/common 
-I/usr/src/cddl/sbin/zfs/../../../cddl/contrib/opensolaris/lib/libumem/common 
-I/usr/src/cddl/sbin/zfs/../../../cddl/contrib/opensolaris/lib/libnvpair 
-I/usr/src/cddl/sbin/zfs/../../../sys/cddl/contrib/opensolaris/uts/common 
-I/usr/src/cddl/sbin/zfs/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs 
-I/usr/src/cddl/sbin/zfs/../../../sys/cddl/contrib/opensolaris/uts/common/sys 
-DNEED_SOLARIS_BOOLEAN -std=gnu89 
-fstack-protector -Wno-unknown-pragmas -c 
/usr/src/cddl/sbin/zfs/../../../cddl/contrib/opensolaris/cmd/zfs/zfs_iter.c
cc -O2 
-pipe 
-I/usr/src/cddl/sbin/zfs/../../../cddl/contrib/opensolaris/lib/libzpool/common 
-I/usr/src/cddl/sbin/zfs/../../../cddl/compat/opensolaris/include 
-I/usr/src/cddl/sbin/zfs/../../../cddl/compat/opensolaris/lib/libumem 
-I/usr/src/cddl/sbin/zfs/../../../sys/cddl/compat/opensolaris 
-I/usr/src/cddl/sbin/zfs/../../../cddl/contrib/opensolaris/head 
-I/usr/src/cddl/sbin/zfs/../../../cddl/contrib/opensolaris/lib/libuutil/common 
-I/usr/src/cddl/sbin/zfs/../../../cddl/contrib/opensolaris/lib/libzfs/common 
-I/usr/src/cddl/sbin/zfs/../../../cddl/contrib/opensolaris/lib/libumem/common 
-I/usr/src/cddl/sbin/zfs/../../../cddl/contrib/opensolaris/lib/libnvpair 
-I/usr/src/cddl/sbin/zfs/../../../sys/cddl/contrib/opensolaris/uts/common 
-I/usr/src/cddl/sbin/zfs/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs 
-I/usr/src/cddl/sbin/zfs/../../../sys/cddl/contrib/opensolaris/uts/common/sys 
-DNEED_SOLARIS_BOOLEAN -std=gnu89 
-fstack-protector -Wno-unknown-pragmas  -o zfs 
zfs_main.o zfs_iter.o -lzfs -lgeom -lbsdxml -lsbuf  -lm -lnvpair -luutil -lutil

/usr/obj/usr/src/tmp/usr/lib/libzfs.so: undefined reference to `getmntent'
*** Error code 1

Stop in /usr/src/cddl/sbin/zfs.
*** Error code 1

Stop in /usr/src/cddl/sbin.
*** Error code 1

Stop in /usr/src/cddl.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.

---Mike



Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,m...@sentex.net
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"