Re: RFT: ZFS MFC
On 20 May 2009, at 1:01, Kip Macy wrote: I would recommend that you use the ZFS_MFC branch - it is the same as what will be in RELENG_7 tomorrow afternoon. This is great news, and given the testing it should be no problem I feel... After setting vm.kmem_size to the recommended minimum I ran buildworld (which resides on a compressed zfs volume) while doing some ufs - zfs and v.v. rsyncs. This was on FreeBSD/amd64 inside VMWare fusion using both v6 and v13 on the zpool (single device, no mirroring/raid) Thanks for all the hard work! Regards, Ruben ___ 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: RFT: ZFS MFC
Unfortunately not a lot but we can do the following: - Donate some hardware (Fibre Channel HBAs) to the FreeBSD project (paid from my pocket, not my employer's one); - Donate some money (paid from my employer's pocket, if I can demonstrate that this can help us to save big bucks on high-end storage systems); - Detail in a very precise way all the tests that we are doing on ZFS, using the following storage: Apple Xraid, Nexsan Sas/SATAbeast, EMC (waiting for the final configuration) as a contribution to the FreeBSD community. In a few words, please let the community know what we can do in order to make this dream come true. Contributing hardware to the cluster increases the range of platforms that FreeBSD committers can test on. I can't speak to whom or to what to contribute money - that really depends on your perceived needs. 4GB / 8GB qlogic fibre channel support is actually on its way, although I don't know the date. Cheers, Kip ___ 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: RFT: ZFS MFC
On Mon, 18 May 2009, Dimitry Andric wrote: DA On 2009-05-16 02:02, Kip Macy wrote: DA I've MFC'd ZFS v13 to RELENG_7 in a work branch. Please test if you can. DA DA http://svn.freebsd.org/base/user/kmacy/ZFS_MFC/ DA DA The standard disclaimers apply. This has only been lightly tested in a DA VM. Please do not use it with data you care about at this time. DA DA For people that would like to test this without building, e.g. to easily DA install on a spare box or VM, I have put up some snapshot ISOs of this DA branch, at r192269 (for i386): DA DA http://www.andric.com/freebsd/zfs13/r192269/ DA DA Note: these don't contain a full ports collection, but enough to get a DA basic system installed, or a LiveCD/DVD started. DA DA Also, if you encounter issues with these ISOs that don't have to do with DA ZFS, please don't bother Kip, but me instead. :) Would you please also post diff to RELENG_7 there? I tried to produce it myself, but got stuck somewhere between SVN and CVS working copies ;-) Thanks! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ 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: RFT: ZFS MFC
On 2009-05-19 13:33, Dmitry Morozovsky wrote: Would you please also post diff to RELENG_7 there? http://www.andric.com/freebsd/zfs13/r192269/zfs_mfc-r192269.diff.bz2 This diff should apply with no fuzz and no rejects to RELENG_7 as of r192386 (2009-05-19 15:33:41 UTC). For earlier or later revisions, no warranty. ;) ___ 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: RFT: ZFS MFC
On Tue, 19 May 2009, Dimitry Andric wrote: DA Would you please also post diff to RELENG_7 there? DA DA http://www.andric.com/freebsd/zfs13/r192269/zfs_mfc-r192269.diff.bz2 DA DA This diff should apply with no fuzz and no rejects to RELENG_7 as of DA r192386 (2009-05-19 15:33:41 UTC). For earlier or later revisions, no DA warranty. ;) Thank you, will try tonight! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ 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: RFT: ZFS MFC
http://www.andric.com/freebsd/zfs13/r192269/zfs_mfc-r192269.diff.bz2 Thanks - am going to gve this a try later. Preseumably if I leave the pool at the revision it is currently on then I can revert back easily ? Also, is this the version which no longer requires any tuning parameters in loader.conf ? That would be extermely interesting! -pete. ___ 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: RFT: ZFS MFC
On 2009-05-19 19:41, Pete French wrote: http://www.andric.com/freebsd/zfs13/r192269/zfs_mfc-r192269.diff.bz2 Thanks - am going to gve this a try later. Preseumably if I leave the pool at the revision it is currently on then I can revert back easily ? I'll just repeat what Kip told us, The standard disclaimers apply. This has only been lightly tested in a VM. Please do not use it with data you care about at this time. That said, zpool(1M) tells: zpool upgrade [-V version] -a | pool ... Upgrades the given pool to the latest on-disk version. Once this is done, the pool will no longer be accessible on systems running older versions of the software. and later on: -V versionUpgrade to the specified version. If the -V flag is not specified, the pool is upgraded to the most recent version. This option can only be used to increase the version number, and only up to the most recent version supported by this software. E.g. you can upgrade pools to ZFS v13, but there's no way back. If you don't upgrade your pool, it should not destroy anything (but don't count on it!), but you won't be able to test any new features either... Also, is this the version which no longer requires any tuning parameters in loader.conf ? That would be extermely interesting! As far as I know, the tuning stuff still applies, especially for i386. On my i386 test VM with 1GB RAM, vm.kmem_size is about 163 MiB without any tuning, while vm.kmem_size_max is about 320 MiB, so you get the warning: ZFS WARNING: Recommended minimum kmem_size is 512MB; expect unstable behavior. Consider tuning vm.kmem_size and vm.kmem_size_max in /boot/loader.conf. So please test, and let us know your findings. :) ___ 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: RFT: ZFS MFC
Many people are happily running an old pool with the new code. I have done that in a VM and run load over it just to be certain. The tuning still applies to i386. On amd64 vm backpressure works, but may actually be too aggressive - shrinking the ARC in favor of the inactive pages queue. Cheers, Kip On Tue, May 19, 2009 at 12:54 PM, Dimitry Andric dimi...@andric.com wrote: On 2009-05-19 19:41, Pete French wrote: http://www.andric.com/freebsd/zfs13/r192269/zfs_mfc-r192269.diff.bz2 Thanks - am going to gve this a try later. Preseumably if I leave the pool at the revision it is currently on then I can revert back easily ? I'll just repeat what Kip told us, The standard disclaimers apply. This has only been lightly tested in a VM. Please do not use it with data you care about at this time. That said, zpool(1M) tells: zpool upgrade [-V version] -a | pool ... Upgrades the given pool to the latest on-disk version. Once this is done, the pool will no longer be accessible on systems running older versions of the software. and later on: -V version Upgrade to the specified version. If the -V flag is not specified, the pool is upgraded to the most recent version. This option can only be used to increase the version number, and only up to the most recent version supported by this software. E.g. you can upgrade pools to ZFS v13, but there's no way back. If you don't upgrade your pool, it should not destroy anything (but don't count on it!), but you won't be able to test any new features either... Also, is this the version which no longer requires any tuning parameters in loader.conf ? That would be extermely interesting! As far as I know, the tuning stuff still applies, especially for i386. On my i386 test VM with 1GB RAM, vm.kmem_size is about 163 MiB without any tuning, while vm.kmem_size_max is about 320 MiB, so you get the warning: ZFS WARNING: Recommended minimum kmem_size is 512MB; expect unstable behavior. Consider tuning vm.kmem_size and vm.kmem_size_max in /boot/loader.conf. So please test, and let us know your findings. :) ___ 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 -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke ___ 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: RFT: ZFS MFC
On Tue, 19 May 2009, Dimitry Andric wrote: DA http://www.andric.com/freebsd/zfs13/r192269/zfs_mfc-r192269.diff.bz2 DA DA Thanks - am going to gve this a try later. Preseumably if I leave the DA pool at the revision it is currently on then I can revert back easily ? DA DA I'll just repeat what Kip told us, The standard disclaimers apply. DA This has only been lightly tested in a VM. Please do not use it with DA data you care about at this time. DA DA That said, zpool(1M) tells: DA DAzpool upgrade [-V version] -a | pool ... DA DAUpgrades the given pool to the latest on-disk version. Once this is DAdone, the pool will no longer be accessible on systems running DAolder versions of the software. DA DA and later on: DA DA-V versionUpgrade to the specified version. If the -V flag is DA not specified, the pool is upgraded to the most DA recent version. This option can only be used to DA increase the version number, and only up to the most DA recent version supported by this software. DA DA E.g. you can upgrade pools to ZFS v13, but there's no way back. If you DA don't upgrade your pool, it should not destroy anything (but don't count DA on it!), but you won't be able to test any new features either... Well, I know this well, but for my particular case I should at least test one case where previous ZFS implementation panics on *read* access to one particular inode; then I hope to convince Kip to dig into the case deep enough to fix it ;-) FWIW, I use ZFS on FreeBSD from the moment it hits RELENG_7, though not too high load patterns, and have no major isues so far, modulo this one and obvious kmem exhastion. Even more is my intention to fix this ;-) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ 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: RFT: ZFS MFC
Dimitry, On Tue, 19 May 2009, Dimitry Andric wrote: DA Would you please also post diff to RELENG_7 there? DA DA http://www.andric.com/freebsd/zfs13/r192269/zfs_mfc-r192269.diff.bz2 DA DA This diff should apply with no fuzz and no rejects to RELENG_7 as of DA r192386 (2009-05-19 15:33:41 UTC). For earlier or later revisions, no DA warranty. ;) Just to be sure: is the patch based on sys/ hierarchy, and does not touch others (like sbin/)? so, basically, cd /usr/src/sys patch /path/to/zfs-mfc.patch should be ok? Thanks again! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ 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: RFT: ZFS MFC
On Wed, 20 May 2009, Dmitry Morozovsky wrote: DM DA http://www.andric.com/freebsd/zfs13/r192269/zfs_mfc-r192269.diff.bz2 DM DA DM DA This diff should apply with no fuzz and no rejects to RELENG_7 as of DM DA r192386 (2009-05-19 15:33:41 UTC). For earlier or later revisions, no DM DA warranty. ;) DM DM Just to be sure: is the patch based on sys/ hierarchy, and does not touch DM others (like sbin/)? DM DM so, basically, DM DM cd /usr/src/sys patch /path/to/zfs-mfc.patch DM DM should be ok? Argh. Answering to myself: no. Even after ``patch -p1'' under /usr/src I got ma...@moose:/usr/src find . -iname '*rej' ./sys/cddl/compat/opensolaris/sys/acl.h.rej ./sys/cddl/contrib/opensolaris/uts/common/sys/dtrace_impl.h.rej ./sys/cddl/contrib/opensolaris/common/atomic/ia64/atomic.S.rej Will investigate further... -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ 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: RFT: ZFS MFC
On Wed, 20 May 2009, Dmitry Morozovsky wrote: DM DM DA http://www.andric.com/freebsd/zfs13/r192269/zfs_mfc-r192269.diff.bz2 DM DM DA DM DM DA This diff should apply with no fuzz and no rejects to RELENG_7 as of DM DM DA r192386 (2009-05-19 15:33:41 UTC). For earlier or later revisions, no DM DM DA warranty. ;) DM DM DM DM Just to be sure: is the patch based on sys/ hierarchy, and does not touch DM DM others (like sbin/)? DM DM DM DM so, basically, DM DM DM DM cd /usr/src/sys patch /path/to/zfs-mfc.patch DM DM DM DM should be ok? DM DM Argh. Answering to myself: no. Even after ``patch -p1'' under /usr/src I got DM DM ma...@moose:/usr/src find . -iname '*rej' DM ./sys/cddl/compat/opensolaris/sys/acl.h.rej DM ./sys/cddl/contrib/opensolaris/uts/common/sys/dtrace_impl.h.rej DM ./sys/cddl/contrib/opensolaris/common/atomic/ia64/atomic.S.rej DM DM Will investigate further... Aha, it seems first and third files are absent in your tree, and second is just $FreeBSD tag differ... Well, let's try to start compile phase ;) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ 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: RFT: ZFS MFC
Many people are happily running an old pool with the new code. I have done that in a VM and run load over it just to be certain. The tuning still applies to i386. On amd64 vm backpressure works, but may actually be too aggressive - shrinking the ARC in favor of the inactive pages queue. I haven't had any i386 code around for a long while, so I will just try it as-is. Just need to fin ish moving tghe machine up to todays -STABLE before applying the patchset (which involved hand fixing bce). Then, all being well I shall (the_winds)caution to coin an old C joke, and run this up on one of our production DNS servers to see how it goes. cheers, -pete. ___ 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: RFT: ZFS MFC
On 2009-05-19 22:10, Dmitry Morozovsky wrote: Just to be sure: is the patch based on sys/ hierarchy, and does not touch others (like sbin/)? No, it touches stuff in cddl/ too, so you need to build the world. Be sure to use -E with patch, to cleanup emptied files. E.g.: patch -d /usr/src -p1 -f -F0 -E -i /path/to/zfs-mfc.patch ___ 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: RFT: ZFS MFC
On Tue, 19 May 2009, Dimitry Andric wrote: DA On 2009-05-19 22:10, Dmitry Morozovsky wrote: DA Just to be sure: is the patch based on sys/ hierarchy, and does not touch DA others (like sbin/)? DA DA No, it touches stuff in cddl/ too, so you need to build the world. Be DA sure to use -E with patch, to cleanup emptied files. E.g.: DA DA patch -d /usr/src -p1 -f -F0 -E -i /path/to/zfs-mfc.patch Hmm, not too much success there: (in the process of building kernel) === zfs (all) cc -O2 -fno-strict-aliasing -pipe -march=athlon-mp -DFREEBSD_NAMECACHE -DBUILDING_ZFS -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/usr/src/sys/modules/zfs/../../cddl/compat/opensolaris -I/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs -I/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/zmod -I/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common -I/usr/src/sys/modules/zfs/../.. -I/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/zfs -I/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common -I/usr/src/sys/modules/zfs/../../../include -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/MOOSE/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/usr/obj/usr/src/sys/MOOSE -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch -Wno-pointer-arith -c /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/acl/acl_common.c In file included from /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/acl/acl_common.h:33, from /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/acl/acl_common.c:36: /usr/src/sys/modules/zfs/../../cddl/compat/opensolaris/sys/acl.h:35: error: conflicting types for 'aclent_t' /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/sys/acl.h:43: error: previous declaration of 'aclent_t' was here /usr/src/sys/modules/zfs/../../cddl/compat/opensolaris/sys/acl.h:40: error: redefinition of 'struct ace' /usr/src/sys/modules/zfs/../../cddl/compat/opensolaris/sys/acl.h:45: error: redefinition of typedef 'ace_t' /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/sys/acl.h:50: error: previous declaration of 'ace_t' was here In file included from /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/acl/acl_common.h:33, from /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/acl/acl_common.c:36: /usr/src/sys/modules/zfs/../../cddl/compat/opensolaris/sys/acl.h:124:1: warning: ACE_TYPE_FLAGS redefined [much more after these...] Or, should I rebuild world previously? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ 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: RFT: ZFS MFC
On Wed, 20 May 2009, Dmitry Morozovsky wrote: DM DA Just to be sure: is the patch based on sys/ hierarchy, and does not touch DM DA others (like sbin/)? DM DA DM DA No, it touches stuff in cddl/ too, so you need to build the world. Be DM DA sure to use -E with patch, to cleanup emptied files. E.g.: DM DA DM DA patch -d /usr/src -p1 -f -F0 -E -i /path/to/zfs-mfc.patch After cleaning /usr/obj and buildworld in single thread I got === cddl/lib/libzfs (all) cc -O2 -fno-strict-aliasing -pipe -march=athlon-mp -DZFS_NO_ACL -I/usr/src/cddl/lib/libzfs/../../../sbin/mount -I/usr/src/cddl/lib/libzfs/../../../cddl/lib/libumem -I/usr/src/cddl/lib/libzfs/../../../sys/cddl/compat/opensolaris -I/usr/src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/include -I/usr/src/cddl/lib/libzfs/../../../cddl/compat/opensolaris/lib/libumem -I/usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/usr/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs -I/usr/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/usr/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/sys -I/usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/head -I/usr/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common -I/usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libnvpair -I/usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libuutil/common -I/usr/src/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-unknown-pragmas -c /usr/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs/zfs_prop.c In file included from /usr/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_acl.h:34, from /usr/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs/zfs_prop.c:29: /usr/src/cddl/lib/libzfs/../../../sys/cddl/compat/opensolaris/sys/acl.h:35: error: conflicting types for 'aclent_t' /usr/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/sys/acl.h:43: error: previous declaration of 'aclent_t' was here /usr/src/cddl/lib/libzfs/../../../sys/cddl/compat/opensolaris/sys/acl.h:40: error: redefinition of 'struct ace' /usr/src/cddl/lib/libzfs/../../../sys/cddl/compat/opensolaris/sys/acl.h:45: error: redefinition of typedef 'ace_t' /usr/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/sys/acl.h:50: error: previous declaration of 'ace_t' was here In file included from /usr/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_acl.h:34, from /usr/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs/zfs_prop.c:29: /usr/src/cddl/lib/libzfs/../../../sys/cddl/compat/opensolaris/sys/acl.h:124:1: warning: ACE_TYPE_FLAGS redefined In file included from /usr/src/cddl/lib/libzfs/../../../sys/cddl/compat/opensolaris/sys/acl.h:31, from /usr/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_acl.h:34, from /usr/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/common/zfs/zfs_prop.c:29: /usr/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/sys/acl.h:178:1: warning: this is the location of the previous definition Any hints? Thanks! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ 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: RFT: ZFS MFC
On 2009-05-19 23:08, Dmitry Morozovsky wrote: After cleaning /usr/obj and buildworld in single thread I got /usr/src/cddl/lib/libzfs/../../../sys/cddl/compat/opensolaris/sys/acl.h:35: error: conflicting types for 'aclent_t' /usr/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/sys/acl.h:43: error: previous declaration of 'aclent_t' was here You probably didn't use -E with patch, the following files can be removed manually afterwards: sys/cddl/compat/opensolaris/sys/acl.h sys/cddl/contrib/opensolaris/common/atomic/amd64/atomic.S sys/cddl/contrib/opensolaris/common/atomic/i386/atomic.S sys/cddl/contrib/opensolaris/common/atomic/ia64/atomic.S sys/cddl/contrib/opensolaris/common/atomic/sparc64/atomic.S sys/cddl/contrib/opensolaris/uts/common/rpc/xdr.c sys/cddl/contrib/opensolaris/uts/common/rpc/xdr_array.c sys/cddl/contrib/opensolaris/uts/common/rpc/xdr_mem.c sys/cddl/contrib/opensolaris/uts/common/sys/vfs.h sys/cddl/contrib/opensolaris/uts/common/zmod/crc32.c My copy is currently still buildworlding, and hasn't failed yet... ___ 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: RFT: ZFS MFC
On Tue, 19 May 2009, Dimitry Andric wrote: DA On 2009-05-19 23:08, Dmitry Morozovsky wrote: DA After cleaning /usr/obj and buildworld in single thread I got DA DA /usr/src/cddl/lib/libzfs/../../../sys/cddl/compat/opensolaris/sys/acl.h:35: DA error: conflicting types for 'aclent_t' DA /usr/src/cddl/lib/libzfs/../../../sys/cddl/contrib/opensolaris/uts/common/sys/acl.h:43: DA error: previous declaration of 'aclent_t' was here DA DA You probably didn't use -E with patch, the following files can be DA removed manually afterwards: DA DA sys/cddl/compat/opensolaris/sys/acl.h DA sys/cddl/contrib/opensolaris/common/atomic/amd64/atomic.S DA sys/cddl/contrib/opensolaris/common/atomic/i386/atomic.S DA sys/cddl/contrib/opensolaris/common/atomic/ia64/atomic.S DA sys/cddl/contrib/opensolaris/common/atomic/sparc64/atomic.S DA sys/cddl/contrib/opensolaris/uts/common/rpc/xdr.c DA sys/cddl/contrib/opensolaris/uts/common/rpc/xdr_array.c DA sys/cddl/contrib/opensolaris/uts/common/rpc/xdr_mem.c DA sys/cddl/contrib/opensolaris/uts/common/sys/vfs.h DA sys/cddl/contrib/opensolaris/uts/common/zmod/crc32.c DA DA My copy is currently still buildworlding, and hasn't failed yet... DA Well, I'm pretty sure I did use -E, but whatever, I removed them by hand, clean up /usr/obj again, and restart buildworld/buildkernel... ... okie, build went into depend phase, while before it breaks on lib phase. maybe I didn't clean someleftovers, or something other go wrong, we'll see... maybe I left some unusual leftovers in /usr/obj; but again, most of files I had to remove by hand (your list) survived ``patch -E''; I'll try to reproduce this tomorrow... ... but then again, on `build all'' phase, I got === cddl/sbin/zpool (all) cc -O2 -fno-strict-aliasing -pipe -march=athlon-mp -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/usr/src/cddl/sbin/zpool/../../../cddl/compat/opensolaris/include -I/usr/src/cddl/sbin/zpool/../../../cddl/compat/opensolaris/lib/libumem -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/compat/opensolaris -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/head -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libuutil/common -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libumem/common -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libzfs/common -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libnvpair -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-unknown-pragmas -o zpool zpool_main.o zpool_vdev.o zpool_iter.o zpool_util.o -lavl -lzfs -lgeom -lbsdxml -lsbuf -lm -lnvpair -luutil -lutil zpool_main.o(.text+0x61ff): In function `zpool_do_create': : undefined reference to `zfs_allocatable_devs' *** Error code 1 well, time to have abit of sleep to have energy to attack it further ;-) Thanks again! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ 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: RFT: ZFS MFC
On 2009-05-19 23:57, Dmitry Morozovsky wrote: ... but then again, on `build all'' phase, I got === cddl/sbin/zpool (all) cc -O2 -fno-strict-aliasing -pipe -march=athlon-mp -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/usr/src/cddl/sbin/zpool/../../../cddl/compat/opensolaris/include -I/usr/src/cddl/sbin/zpool/../../../cddl/compat/opensolaris/lib/libumem -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/compat/opensolaris -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/head -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libuutil/common -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libumem/common -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libzfs/common -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libnvpair -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-unknown-pragmas -o zpool zpool_main.o zpool_vdev.o zpool_iter.o zpool_util.o -lavl -lzfs -lgeom -lbsdxml -lsbuf -lm -lnvpair -luutil -lutil zpool_main.o(.text+0x61ff): In function `zpool_do_create': : undefined reference to `zfs_allocatable_devs' *** Error code 1 FWIW, I just did a full buildworld, kernel, reboot, installworld dance, there were no errors. You may possibly have some cruft left in obj, or you could zap your src tree and start fresh? :) ___ 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: RFT: ZFS MFC
I created a branch for a reason. With all the renames applying a patch is a nightmare. Either use the branch or wait until I do the MFC. Cheers, Kip On Tue, May 19, 2009 at 3:49 PM, Dimitry Andric dimi...@andric.com wrote: On 2009-05-19 23:57, Dmitry Morozovsky wrote: ... but then again, on `build all'' phase, I got === cddl/sbin/zpool (all) cc -O2 -fno-strict-aliasing -pipe -march=athlon-mp -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libzpool/common -I/usr/src/cddl/sbin/zpool/../../../cddl/compat/opensolaris/include -I/usr/src/cddl/sbin/zpool/../../../cddl/compat/opensolaris/lib/libumem -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/compat/opensolaris -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/head -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libuutil/common -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libumem/common -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libzfs/common -I/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/lib/libnvpair -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/contrib/opensolaris/common/zfs -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/contrib/opensolaris/uts/common -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/usr/src/cddl/sbin/zpool/../../../sys/cddl/contrib/opensolaris/uts/common/sys -DNEED_SOLARIS_BOOLEAN -std=gnu89 -Wno-unknown-pragmas -o zpool zpool_main.o zpool_vdev.o zpool_iter.o zpool_util.o -lavl -lzfs -lgeom -lbsdxml -lsbuf -lm -lnvpair -luutil -lutil zpool_main.o(.text+0x61ff): In function `zpool_do_create': : undefined reference to `zfs_allocatable_devs' *** Error code 1 FWIW, I just did a full buildworld, kernel, reboot, installworld dance, there were no errors. You may possibly have some cruft left in obj, or you could zap your src tree and start fresh? :) ___ 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 -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke ___ 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: RFT: ZFS MFC
On Tue, 19 May 2009, Kip Macy wrote: KM I created a branch for a reason. With all the renames applying a patch KM is a nightmare. Either use the branch or wait until I do the MFC. Ah well, Kip, thank you for all of your support. Then, what would you offer for releng_7 users to test your changes? I'm more than happy to test, and I'm ready to be unvolved in some clashes resolved, but... Anyway, thank you for all your efforts you put there! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ 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: RFT: ZFS MFC
On Tue, May 19, 2009 at 4:00 PM, Dmitry Morozovsky ma...@rinet.ru wrote: On Tue, 19 May 2009, Kip Macy wrote: KM I created a branch for a reason. With all the renames applying a patch KM is a nightmare. Either use the branch or wait until I do the MFC. Ah well, Kip, thank you for all of your support. Then, what would you offer for releng_7 users to test your changes? I'm more than happy to test, and I'm ready to be unvolved in some clashes resolved, but... Anyway, thank you for all your efforts you put there! I would recommend that you use the ZFS_MFC branch - it is the same as what will be in RELENG_7 tomorrow afternoon. Cheers, Kip ___ 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: RFT: ZFS MFC
On Tue, 19 May 2009, Kip Macy wrote: KM Ah well, Kip, thank you for all of your support. KM KM Then, what would you offer for releng_7 users to test your changes? I'm more KM than happy to test, and I'm ready to be unvolved in some clashes resolved, KM but... KM KM Anyway, thank you for all your efforts you put there! KM KM KM I would recommend that you use the ZFS_MFC branch - it is the same as KM what will be in RELENG_7 tomorrow afternoon. Well, then I'll keep my energy for a day or two, escaping from painful SVN-CVS mass merges ;-) Thanks again. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ 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: RFT: ZFS MFC
On 2009-05-16 02:02, Kip Macy wrote: I've MFC'd ZFS v13 to RELENG_7 in a work branch. Please test if you can. http://svn.freebsd.org/base/user/kmacy/ZFS_MFC/ The standard disclaimers apply. This has only been lightly tested in a VM. Please do not use it with data you care about at this time. For people that would like to test this without building, e.g. to easily install on a spare box or VM, I have put up some snapshot ISOs of this branch, at r192269 (for i386): http://www.andric.com/freebsd/zfs13/r192269/ Note: these don't contain a full ports collection, but enough to get a basic system installed, or a LiveCD/DVD started. Also, if you encounter issues with these ISOs that don't have to do with ZFS, please don't bother Kip, but me instead. :) ___ 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: RFT: ZFS MFC
Kip, On Fri, 15 May 2009, Kip Macy wrote: KM I've MFC'd ZFS v13 to RELENG_7 in a work branch. Please test if you can. KM KM http://svn.freebsd.org/base/user/kmacy/ZFS_MFC/ KM KM The standard disclaimers apply. This has only been lightly tested in a KM VM. Please do not use it with data you care about at this time. maybe you have time and ability to investigate my panic: avl_find() succeeded inside avl_add() I reported at 4 Apr? I can even provide you with serial console if it's needed. Thank you in advance! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ 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: RFT: ZFS MFC
I will if you can reproduce on this branch. A lot has changed between ZFS v7 and ZFS v13. -Kip On Sun, May 17, 2009 at 3:48 AM, Dmitry Morozovsky ma...@rinet.ru wrote: Kip, On Fri, 15 May 2009, Kip Macy wrote: KM I've MFC'd ZFS v13 to RELENG_7 in a work branch. Please test if you can. KM KM http://svn.freebsd.org/base/user/kmacy/ZFS_MFC/ KM KM The standard disclaimers apply. This has only been lightly tested in a KM VM. Please do not use it with data you care about at this time. maybe you have time and ability to investigate my panic: avl_find() succeeded inside avl_add() I reported at 4 Apr? I can even provide you with serial console if it's needed. Thank you in advance! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke ___ 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: RFT: ZFS MFC
On Sun, 17 May 2009, Kip Macy wrote: KM I will if you can reproduce on this branch. A lot has changed between KM ZFS v7 and ZFS v13. So, if I understand you correctrly, you wish me to upgrade to the latest sources including RELENG_7 ZFS patches, but do *NOT* upgrade the pool to V13? Hopefully, provided ZFS snapshots work right (they did on my previous tests, and for now I moved the offending directory out of usage, and disabled cron due to daily security find) I can try this tomorrow. KM maybe you have time and ability to investigate my panic: avl_find() succeeded KM inside avl_add() I reported at 4 Apr? KM KM I can even provide you with serial console if it's needed. KM KM Thank you in advance! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ 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: RFT: ZFS MFC
On Sun, May 17, 2009 at 3:19 PM, Dmitry Morozovsky ma...@rinet.ru wrote: On Sun, 17 May 2009, Kip Macy wrote: KM I will if you can reproduce on this branch. A lot has changed between KM ZFS v7 and ZFS v13. So, if I understand you correctrly, you wish me to upgrade to the latest sources including RELENG_7 ZFS patches, but do *NOT* upgrade the pool to V13? Hopefully, provided ZFS snapshots work right (they did on my previous tests, and for now I moved the offending directory out of usage, and disabled cron due to daily security find) I can try this tomorrow. I don't know how well V7 will work with the latest sources. Too much has changed for me to support V7. I may create a branch with the MFC against 7.2 if you need to be on a release. Cheers, Kip ___ 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: RFT: ZFS MFC
Kip, On Sun, 17 May 2009, Kip Macy wrote: KM KM I will if you can reproduce on this branch. A lot has changed between KM KM ZFS v7 and ZFS v13. KM KM So, if I understand you correctrly, you wish me to upgrade to the latest KM sources including RELENG_7 ZFS patches, but do *NOT* upgrade the pool to V13? KM KM Hopefully, provided ZFS snapshots work right (they did on my previous tests, KM and for now I moved the offending directory out of usage, and disabled cron due KM to daily security find) I can try this tomorrow. KM KM KM I don't know how well V7 will work with the latest sources. Too much KM has changed for me to support V7. I may create a branch with the MFC KM against 7.2 if you need to be on a release. This would save a bit (or a bunch, who knows? ;-) of time to integrate a patch. BTW, the server in question is very next to 7.2-R. Kernel with KDB, serial console are in place. All data are actually backed up around, but the server is in operational state (tthough not vital to other company needs), so I would just hope not to regenerate all from scratch if at all possible. Thank you again! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ 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: RFT: ZFS MFC
On Fri, May 15, 2009 at 05:02:22PM -0700, Kip Macy wrote: I've MFC'd ZFS v13 to RELENG_7 in a work branch. Please test if you can. http://svn.freebsd.org/base/user/kmacy/ZFS_MFC/ The standard disclaimers apply. This has only been lightly tested in a VM. Please do not use it with data you care about at this time. Thanks, Kip Seems to work for me so far. I had a zfs send hang part way through and with a notable speed difference depending on the direction but this is literally the first time I've tried zfs send/recv and the systems are setup different so I have no idea if it would have happened anyway. Eventually I could probably make these test systems more similar to give a fair test, but wanted to mention it so others could check. Thanks for working on the MFC, I'm excited to see progress there! It will play a factor in some upcoming server plans even if the MFC doesn't happen for months. ___ 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: RFT: ZFS MFC
On 5/15/09 8:02 PM, Kip Macy wrote: I've MFC'd ZFS v13 to RELENG_7 in a work branch. Please test if you can. http://svn.freebsd.org/base/user/kmacy/ZFS_MFC/ The standard disclaimers apply. This has only been lightly tested in a VM. Please do not use it with data you care about at this time. Thanks, Kip I created a pool on 7.1, created some datasets, populated them, made some snapshots. Upgraded to v13 deleted a few snapshots, created a clone, promoted a clone, deleted and created some new datasets. So far so good. I'll try to make something break! ___ 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: RFT: ZFS MFC
On May 16, 2009, at 8:50 AM, Adam McDougall wrote: On Fri, May 15, 2009 at 05:02:22PM -0700, Kip Macy wrote: I've MFC'd ZFS v13 to RELENG_7 in a work branch. Please test if you can. http://svn.freebsd.org/base/user/kmacy/ZFS_MFC/ The standard disclaimers apply. This has only been lightly tested in a VM. Please do not use it with data you care about at this time. Thanks, Kip Seems to work for me so far. I had a zfs send hang part way through and with a notable speed difference depending on the direction but this is literally the first time I've tried zfs send/recv and the systems are setup different so I have no idea if it would have happened anyway. Eventually I could probably make these test systems more similar to give a fair test, but wanted to mention it so others could check. Thanks for working on the MFC, I'm excited to see progress there! It will play a factor in some upcoming server plans even if the MFC doesn't happen for months. ___ 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 We're now testing ZFS under FreeBSD (7.2 and CURRENT) quite extensively, because our primary goal is to setup a fileserver that can scale up to 80TB using high-density, low-cost storage (2TB SATA II disks in a 42 bay, 4 unit storage). The fact that ZFS v13 has been MFC'ed sounds good to me. I'd like to recommend to test the most basic physical stress conditions, eg: - Pulling out one healthy disk in a raidz2 pool; - Pulling it back and see if resilvering starts in a reasonable time (we experienced consolle locks, access via SSH to the box was still possible and fully responsive); - Pulling out TWO healthy disks in a raidz2 pool; - Pulling them back one at a time (and two at the same time) and see if the pool is resilvered in a reasonable time; - Too many combinations to be listed here. I'll be more than happy if the FreeBSD community will came out with a sort of ZFS standard stress test suite (both physical and logical), in order to be able to compare the ZFS reliability when used in different scenarios (eg: our scenario is made of a v20Z server with 6Gb RAM directly attached via a 2Gb Qlogic Fibre Channel adapter, the JBOD is an Apple Xraid fully loaded with 450Gb PATA disks, all sysctl parameters set accordingly to the ZFS tuning guide). I'm strongly conviced that, for a number of reasons, FreeBSD + ZFS can be the silver bullet in the enterprise storage just because of the following: PROS: - Solaris/OpenSolaris are limited to an NGROUPS_MAX value of 16 (http://bugs.opensolaris.org/view_bug.do?bug_id=4088757 , http://www.j3e.de/ngroups.html) while FreeBSD isn't (we are using an NGROUPS_MAX value of 64 right now). This is a good point if you are serving hundreds of clients, authenticated via LDAP (Posix accounts RFC 2307) and you are living in a mixed shop (MACs and PCs.. like we do); - Apple is introducing ZFS support on non-bootable storage under OS X 10.6 but nobody really knows what ZFS version will be made available; - License constraints on Linux. ZFS can't be used in kernel mode, only using FUSE at the price of degraded performance (AFAIK); - Maybe I'm missing something but it's ok since I'm slightly drunk as of now. Please help (by suggesting missing points, not by suggesting me to refrain from drinking on Saturday's night ;-). CONS: - FreeBSD is currently lacking an enterprise-level support for modern 4Gb Fibre Channel HBAs, as you can read here: http://lists.freebsd.org/pipermail/freebsd-scsi/2009-April/date.html#3876 -- No reply, AFAIK; http://lists.freebsd.org/pipermail/freebsd-scsi/2008-October/003686.html http://lists.freebsd.org/pipermail/freebsd-scsi/2008-November/003705.html http://lists.freebsd.org/pipermail/freebsd-stable/2008-November/046556.html http://lists.freebsd.org/pipermail/freebsd-stable/2008-November/046602.html Before throwing rotting tomatoes straight to me please consider the following facts: - Our infrastructure is 90% based on FreeBSD. It has proven to be rock solid over a 7 year timespan. Are we happy ? Definitely yes.; - We are grateful to the FreeBSD community, this mail should be intended as a constructive criticism in order to exploit a sweet spot in storage enterprise. This can dramatically leverage the adoption of FreeBSD in the enterprise, if we consider the fact that, due to the global crisis, most enterprises will start to look at low- cost, highly reliable, higly scalable storage systems; - We are also grateful to the Pawel Jakub Dawidek and all the other FreeBSD ZFS contributors, you are doing a great job guys, thanks. What can I do to foster this trend, and being able to further enhance the ZFS support under FreeBSD, provided that we cannot contribute coding skills ? Unfortunately not
RFT: ZFS MFC
I've MFC'd ZFS v13 to RELENG_7 in a work branch. Please test if you can. http://svn.freebsd.org/base/user/kmacy/ZFS_MFC/ The standard disclaimers apply. This has only been lightly tested in a VM. Please do not use it with data you care about at this time. Thanks, Kip -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke ___ 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
