On Wed, May 20, 2009 at 2:59 PM, Kip Macy <kmacy@freebsd.org> wrote:> I will be MFC'ing the newer ZFS support some time this afternoon. Both > world and kernel will need to be re-built. Existing pools will > continue to work without upgrade. > > > If you choose to upgrade a pool to take advantage of new features you > will no longer be able to use it with sources prior to today. 'zfs > send/recv' is not expected to inter-operate between different pool > versions.The MFC went in r192498. Please let me know if you have any problems. Thanks, Kip
On Wed, May 20, 2009 at 4:43 PM, Kip Macy <kmacy@freebsd.org> wrote:> On Wed, May 20, 2009 at 2:59 PM, Kip Macy <kmacy@freebsd.org> wrote: >> I will be MFC'ing the newer ZFS support some time this afternoon. Both >> world and kernel will need to be re-built. Existing pools will >> continue to work without upgrade. >> >> >> If you choose to upgrade a pool to take advantage of new features you >> will no longer be able to use it with sources prior to today. 'zfs >> send/recv' is not expected to inter-operate between different pool >> versions. > > > The MFC went in r192498. Please let me know if you have any problems.Not really a problem but a question: Is the v13 on-disk format exactly the same as that used by Solaris/Opensolaris? Does this make it possible to have a ZFS-only dual boot system running FreeBSD-stable and Solaris, with a shared home directory between the two environments? Has anyone tried anything like this? Regards, Navdeep> > Thanks, > Kip > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >
> Not really a problem but a question: ?Is the v13 on-disk format > exactly the same as that used by Solaris/Opensolaris?It is supposed to be. The sources are the same. However, I have not tested interoperability.> Does this make > it possible to have a ZFS-only dual boot system running FreeBSD-stable > and Solaris, with a shared home directory between the two > environments?It should be.>Has anyone tried anything like this? >Google anyone? :-) -Kip
2009/5/21 Kip Macy <kmacy@freebsd.org>:> On Wed, May 20, 2009 at 2:59 PM, Kip Macy <kmacy@freebsd.org> wrote: >> I will be MFC'ing the newer ZFS support some time this afternoon. Both >> world and kernel will need to be re-built. Existing pools will >> continue to work without upgrade. >> >> >> If you choose to upgrade a pool to take advantage of new features you >> will no longer be able to use it with sources prior to today. 'zfs >> send/recv' is not expected to inter-operate between different pool >> versions. > > > The MFC went in r192498. Please let me know if you have any problems.Please, fix 4 times repetition of all its content in stable/7/cddl/compat/opensolaris/include/libshare.h. Thanks! -- wbr, pluknet
2009/5/21 Kip Macy <kmacy@freebsd.org>:> The MFC went in r192498. Please let me know if you have any problems. > - zfs boot for all types now worksIs it possible to boot from ZFS without ufs boot partition? zfsboot was added but is not build, gptzfsboot is not in tree. -- Artis Caune Everything should be made as simple as possible, but not simpler.
Kip Macy wrote:> On Wed, May 20, 2009 at 2:59 PM, Kip Macy <kmacy@freebsd.org> wrote: >> I will be MFC'ing the newer ZFS support some time this afternoon. Both >> world and kernel will need to be re-built. Existing pools will >> continue to work without upgrade. >> >> >> If you choose to upgrade a pool to take advantage of new features you >> will no longer be able to use it with sources prior to today. 'zfs >> send/recv' is not expected to inter-operate between different pool >> versions. > > > The MFC went in r192498. Please let me know if you have any problems.I upgrade to stable r192523: FreeBSD morzine.restart.bel 7.2-STABLE FreeBSD 7.2-STABLE #0: Thu May 21 13:18:53 CEST 2009 root@morzine.restart.bel:/usr/obj/usr/src/sys/MORZINE i386 some strange things: just after boot: [root@morzine ~]# zfs upgrade This system is currently running ZFS filesystem version 3. The following filesystems are out of date, and can be upgraded. After being upgraded, these filesystems (and any 'zfs send' streams generated from subsequent snapshots) will no longer be accessible by older software versions. VER FILESYSTEM --- ------------ 1 pool1 1 pool1/qemu 1 pool1/squid 1 pool2 1 pool2/WorkBench 1 pool2/backup 1 pool2/download 1 pool2/qemu 1 pool2/sys 1 rpool 1 rpool/home 1 rpool/root 1 rpool/tmp 1 rpool/usr 1 rpool/var 1 rpool/var/spool [root@morzine ~]# zfs upgrade -v The following filesystem versions are supported: VER DESCRIPTION --- -------------------------------------------------------- 1 Initial ZFS filesystem version 2 Enhanced directory entries 3 Case insensitive and File system unique identifer (FUID) For more information on a particular version, including supported releases, see: http://www.opensolaris.org/os/community/zfs/version/zpl/N Where 'N' is the version number. And now, after a few minutes: [root@morzine ~]# zpool upgrade This system is currently running ZFS pool version 13. The following pools are out of date, and can be upgraded. After being upgraded, these pools will no longer be accessible by older software versions. VER POOL --- ------------ 6 pool1 6 pool2 6 rpool Use 'zpool upgrade -v' for a list of available versions and their associated features. [root@morzine ~]# zpool upgrade -v This system is currently running ZFS pool version 13. The following versions are supported: VER DESCRIPTION --- -------------------------------------------------------- 1 Initial ZFS version 2 Ditto blocks (replicated metadata) 3 Hot spares and double parity RAID-Z 4 zpool history 5 Compression using the gzip algorithm 6 bootfs pool property 7 Separate intent log devices 8 Delegated administration 9 refquota and refreservation properties 10 Cache devices 11 Improved scrub performance 12 Snapshot properties 13 snapused property For more information on a particular version, including supported releases, see: http://www.opensolaris.org/os/community/zfs/version/N Where 'N' is the version number. Strange isn't it o-) By the way all seems ok! Thanks to all for this update to zfs V13 Henri> > Thanks, > Kip > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
On Wednesday 20 May 2009 06:43:13 pm Kip Macy wrote:> The MFC went in r192498. Please let me know if you have any problems.So far so good here (amd64, Core2 Duo, ICH9 SATA) but I'm too chicken to upgrade the on-disk format yet. -- Kirk Strauser
All looking good here - 3rd DNS server is now running new ZFS with an upgraded pool, and I jsut did a server in the office which is running a database and filesderver, also upgrading the pool. These are all amd64 systems, and the vm backpressure system seems to work nicely - in that the kernel memory usage has settled at the same kind of levels I was locking it to previously (which is nice to see!). -pete.
Kip Macy wrote:> On Wed, May 20, 2009 at 2:59 PM, Kip Macy <kmacy@freebsd.org> wrote: >> I will be MFC'ing the newer ZFS support some time this afternoon. Both >> world and kernel will need to be re-built. Existing pools will >> continue to work without upgrade. >> >> >> If you choose to upgrade a pool to take advantage of new features you >> will no longer be able to use it with sources prior to today. 'zfs >> send/recv' is not expected to inter-operate between different pool >> versions. > > > The MFC went in r192498. Please let me know if you have any problems. >I get a panic: panic: solaris assert: 0 == dmu_read(os, lr->lr_foid, off, dlen, buf), file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c, line: 991 during `make -s DESTDIR=/kingston installworld` kingston is a pool on a USB stick with GPT partitions more info at : http://verbier.restart.be/xfer/core.txt.60 Thanks for your work Henri> Thanks, > Kip > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
Kip Macy wrote:> On Wed, May 20, 2009 at 2:59 PM, Kip Macy <kmacy@freebsd.org> wrote: >> I will be MFC'ing the newer ZFS support some time this afternoon. Both >> world and kernel will need to be re-built. Existing pools will >> continue to work without upgrade. >> >> >> If you choose to upgrade a pool to take advantage of new features you >> will no longer be able to use it with sources prior to today. 'zfs >> send/recv' is not expected to inter-operate between different pool >> versions. > > > The MFC went in r192498. Please let me know if you have any problems.No a real problem but maybe worth mentioning: on FreeBSD morzine.restart.bel 7.2-STABLE FreeBSD 7.2-STABLE #0: Tue May 26 15:37:48 CEST 2009 root@morzine.restart.bel:/usr/obj/usr/src/sys/MORZINE i386 [root@morzine ~]# zdb rpool version=13 name='rpool' state=0 txg=959 pool_guid=17669857244588609348 hostid=2315842372 hostname='unset' vdev_tree type='root' id=0 guid=17669857244588609348 children[0] type='mirror' id=0 guid=3225603179255348056 metaslab_array=23 metaslab_shift=28 ashift=9 asize=51534888960 is_log=0 children[0] type='disk' id=0 guid=17573085726489368265 path='/dev/da0p2' whole_disk=0 children[1] type='disk' id=1 guid=2736169600077218893 path='/dev/da1p2' whole_disk=0 Assertion failed: (??u??????&), function mp->m_owner == NULL, file /usr/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/kernel.c, line 112. Abort trap: 6 and on FreeBSD avoriaz.restart.bel 7.2-STABLE FreeBSD 7.2-STABLE #0: Mon May 25 12:06:07 CEST 2009 root@avoriaz.restart.bel:/usr/obj/usr/src/sys/AVORIAZ amd64 [root@avoriaz ~]# zdb rpool version=13 name='rpool' state=0 txg=3467 pool_guid=536117255064806899 hostid=1133576597 hostname='unset' vdev_tree type='root' id=0 guid=536117255064806899 children[0] type='mirror' id=0 guid=3124217685892976292 metaslab_array=23 metaslab_shift=30 ashift=9 asize=155741847552 is_log=0 children[0] type='disk' id=0 guid=11099413743436480159 path='/dev/ad4p2' whole_disk=0 children[1] type='disk' id=1 guid=12724983687805955432 path='/dev/ad6p2' whole_disk=0 Segmentation fault: 11 By the way, to help prepare a boot/root pool does a utility to display the content of zpool.cache exist ? Henri> > Thanks, > Kip > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
Kip Macy wrote:> On Wed, May 20, 2009 at 2:59 PM, Kip Macy <kmacy@freebsd.org> wrote: >> I will be MFC'ing the newer ZFS support some time this afternoon. Both >> world and kernel will need to be re-built. Existing pools will >> continue to work without upgrade. >> >> >> If you choose to upgrade a pool to take advantage of new features you >> will no longer be able to use it with sources prior to today. 'zfs >> send/recv' is not expected to inter-operate between different pool >> versions. > > > The MFC went in r192498. Please let me know if you have any problems. >I get a Fatal trap 12: page fault while in kernel mode at shutdown. the core.txt is http://verbier.restart.be/xfer/core.txt.61 Thanks for you work Henri> Thanks, > Kip > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
on 29/05/2009 15:35 Andriy Gapon said the following:> So anyone else feels that this is a bug? > > on 28/05/2009 16:55 Andriy Gapon said the following: >> on 28/05/2009 16:26 Henri Hennebert said the following: >>> (gdb) bt >>> #0 0x00000008012a6f22 in strlen () from /lib/libc.so.7 >>> #1 0x00000008012a0feb in open () from /lib/libc.so.7 >>> #2 0x000000080129ea59 in open () from /lib/libc.so.7 >>> #3 0x00000008012a1f2e in vfprintf () from /lib/libc.so.7 >>> #4 0x0000000801291158 in fprintf () from /lib/libc.so.7 >>> #5 0x0000000801290fb0 in __assert () from /lib/libc.so.7 >> I find the above part interesting. >> Could this be because of the following discrepancy: >> >> 1) >> cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h: >> extern void __assert(const char *, const char *, int); >> 2) >> lib/libc/gen/assert.c: >> void >> __assert(func, file, line, failedexpr) >> const char *func, *file; >> int line; >> const char *failedexpr; >> >>> #6 0x0000000800fef120 in zmutex_destroy () from /lib/libzpool.so.1 >>> #7 0x000000080102e1a0 in dsl_dataset_fast_stat () from /lib/libzpool.so.1 >>> #8 0x0000000801045ffa in dbuf_find () from /lib/libzpool.so.1 >>> #9 0x0000000801047bf3 in dmu_buf_rele () from /lib/libzpool.so.1 >>> #10 0x0000000801027546 in dsl_pool_open () from /lib/libzpool.so.1 >>> #11 0x000000080101bcec in spa_create () from /lib/libzpool.so.1 >>> #12 0x000000080101c820 in spa_tryimport () from /lib/libzpool.so.1I propose the following patch for this issue. It fixes mismatch between __assert extern declaration in zfs code and actual signature in libc code. I also took liberty of dropping __STDC__ and __STDC_VERSION__ checks. I think that those checks are not needed with compilers that can be used to compile FreeBSD. Besides, both branches of __STDC_VERSION__ check were exactly the same. Henri, if you still experience that crash of zpool command, could you please try the patch and see if you have a nicer assert message and stacktrace now? Sorry, that this is still not a fix for the real issue. diff --git a/cddl/contrib/opensolaris/head/assert.h b/cddl/contrib/opensolaris/head/assert.h index 394820a..c2a4936 100644 --- a/cddl/contrib/opensolaris/head/assert.h +++ b/cddl/contrib/opensolaris/head/assert.h @@ -37,15 +37,7 @@ extern "C" { #endif -#if defined(__STDC__) -#if __STDC_VERSION__ - 0 >= 199901L -extern void __assert(const char *, const char *, int); -#else -extern void __assert(const char *, const char *, int); -#endif /* __STDC_VERSION__ - 0 >= 199901L */ -#else -extern void _assert(); -#endif +extern void __assert(const char *, const char *, int, const char *); #ifdef __cplusplus } @@ -68,14 +60,6 @@ extern void _assert(); #else -#if defined(__STDC__) -#if __STDC_VERSION__ - 0 >= 199901L -#define assert(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 0)) -#else -#define assert(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 0)) -#endif /* __STDC_VERSION__ - 0 >= 199901L */ -#else -#define assert(EX) (void)((EX) || (_assert("EX", __FILE__, __LINE__), 0)) -#endif /* __STDC__ */ +#define assert(EX) (void)((EX) || (__assert(__func__, __FILE__, __LINE__, #EX), 0)) #endif /* NDEBUG */ diff --git a/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h b/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h index 7ae7f9d..631e302 100644 --- a/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h +++ b/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h @@ -120,21 +120,12 @@ extern void vpanic(const char *, __va_list); #define fm_panic panic /* This definition is copied from assert.h. */ -#if defined(__STDC__) -#if __STDC_VERSION__ - 0 >= 199901L -#define verify(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 0)) -#else -#define verify(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 0)) -#endif /* __STDC_VERSION__ - 0 >= 199901L */ -#else -#define verify(EX) (void)((EX) || (_assert("EX", __FILE__, __LINE__), 0)) -#endif /* __STDC__ */ - +#define verify(EX) (void)((EX) || (__assert(__func__, __FILE__, __LINE__, #EX), 0)) #define VERIFY verify #define ASSERT assert -extern void __assert(const char *, const char *, int); +extern void __assert(const char *, const char *, int, const char *); #ifdef lint #define VERIFY3_IMPL(x, y, z, t) if (x == z) ((void)0) @@ -148,7 +139,7 @@ extern void __assert(const char *, const char *, int); (void) snprintf(__buf, 256, "%s %s %s (0x%llx %s 0x%llx)", \ #LEFT, #OP, #RIGHT, \ (u_longlong_t)__left, #OP, (u_longlong_t)__right); \ - __assert(__buf, __FILE__, __LINE__); \ + __assert(__func__, __FILE__, __LINE__, __buf); \ } \ _NOTE(CONSTCOND) } while (0) /* END CSTYLED */ -- Andriy Gapon
on 01/06/2009 19:22 Andriy Gapon said the following:> Henri, > > thank you very much for testing! > It look like the patch did its job. > > P.S. hopefully someone is looking into the cause of the assertion.I think I cracked it. This is where ds->ds_lock.m_owner gets corrupted: (gdb) c Continuing. Watchpoint 8: *(void **) 34385649856 Old value = (void *) 0x0 New value = (void *) 0x8018f7ce0 0x0000000800a731e6 in pthread_mutexattr_init () from /lib/libthr.so.3 (gdb) bt #0 0x0000000800a731e6 in pthread_mutexattr_init () from /lib/libthr.so.3 #1 0x0000000800a733ca in pthread_mutex_getyieldloops_np () from /lib/libthr.so.3 #2 0x0000000800a736ab in pthread_mutex_isowned_np () from /lib/libthr.so.3 #3 0x00000008010398e5 in dsl_dataset_evict (db=0x8018c7cf0, dsv=0x8018b6000) at /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:264 ... (gdb) fr 3 #3 0x00000008010398e5 in dsl_dataset_evict (db=0x8018c7cf0, dsv=0x8018b6000) at /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:264 264 if (mutex_owned(&ds->ds_lock)) (gdb) list 259 if (ds->ds_dir) 260 dsl_dir_close(ds->ds_dir, ds); 261 262 ASSERT(!list_link_active(&ds->ds_synced_link)); 263 264 if (mutex_owned(&ds->ds_lock)) 265 mutex_exit(&ds->ds_lock); mutex_owned is defined: cddl/contrib/opensolaris/head/thread.h #define mutex_owned(l) pthread_mutex_isowned_np(l) So we pass kmutex_t* parameter to pthread_mutex_isowned_np call where in fact we should be passing pthread_mutex_t* parameter. So I am quite sure that mutex_owned should be defined as follows: #define mutex_owned(l) pthread_mutex_isowned_np((l)->m_lock) Or it should be called on m_lock member of kmutex_t. Thanks to Henri for all the debugging info! -- Andriy Gapon