ZFS patches. - FreeBSD

This is a discussion on ZFS patches. - FreeBSD ; Hi. http://people.freebsd.org/~pjd/patch...0727.patch.bz2 The patch above contains the most recent ZFS version that could be found in OpenSolaris as of today. Apart for large amount of new functionality, I belive there are many stability (and also performance) improvements compared to the ...

+ Reply to Thread
Results 1 to 19 of 19

Thread: ZFS patches.

  1. ZFS patches.

    Hi.

    http://people.freebsd.org/~pjd/patch...0727.patch.bz2

    The patch above contains the most recent ZFS version that could be found
    in OpenSolaris as of today. Apart for large amount of new functionality,
    I belive there are many stability (and also performance) improvements
    compared to the version from the base system.

    Check out OpenSolaris website to find out the differences between base
    system version and patch version.

    Please test, test, test. If I get enough positive feedback, I may be
    able to squeeze it into 7.1-RELEASE, but this might be hard.

    If you have any questions, please use mailing lists
    (freebsd-fs@FreeBSD.org would be the best).

    Thank you in advance!

    --
    Pawel Jakub Dawidek http://www.wheel.pl
    pjd@FreeBSD.org http://www.FreeBSD.org
    FreeBSD committer Am I Evil? Yes, I Am!

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.4 (FreeBSD)

    iD8DBQFIjG/1ForvXbEpPzQRAnctAJ91c32L6NIndQwEcPai7L9AtYAAJwCfd eEZ
    atAsjYV6T5/dTjD0wljQ+sw=
    =D4oR
    -----END PGP SIGNATURE-----


  2. Re: ZFS patches.

    Pawel Jakub Dawidek schrieb:
    > Hi.
    >
    > http://people.freebsd.org/~pjd/patch...0727.patch.bz2
    >
    > The patch above contains the most recent ZFS version that could be found
    > in OpenSolaris as of today. Apart for large amount of new functionality,
    > I belive there are many stability (and also performance) improvements
    > compared to the version from the base system.
    >
    >

    So this build could import zfs version 3/zpool version 10? Just asking
    because I have a opensolaris box where could try FreeBSD in this case.

    Arne

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


  3. Re: ZFS patches.

    On Sun, 27 Jul 2008, Pawel Jakub Dawidek wrote:

    > Hi.
    >
    > http://people.freebsd.org/~pjd/patch...0727.patch.bz2
    >
    > The patch above contains the most recent ZFS version that could be found
    > in OpenSolaris as of today. Apart for large amount of new functionality,
    > I belive there are many stability (and also performance) improvements
    > compared to the version from the base system.
    >
    > Check out OpenSolaris website to find out the differences between base
    > system version and patch version.
    >
    > Please test, test, test. If I get enough positive feedback, I may be
    > able to squeeze it into 7.1-RELEASE, but this might be hard.
    >
    > If you have any questions, please use mailing lists
    > (freebsd-fs@FreeBSD.org would be the best).


    Is this patch against -stable or -current?

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


  4. Re: ZFS patches.

    On Sun, Jul 27, 2008 at 08:34:00PM +0200, Max Laier wrote:
    > Hi Pawel,
    >
    > On Sunday 27 July 2008 14:54:13 Pawel Jakub Dawidek wrote:
    > > http://people.freebsd.org/~pjd/patch...0727.patch.bz2
    > >
    > > The patch above contains the most recent ZFS version that could be found
    > > in OpenSolaris as of today. Apart for large amount of new functionality,
    > > I belive there are many stability (and also performance) improvements
    > > compared to the version from the base system.

    >
    > nice!
    >
    > > Check out OpenSolaris website to find out the differences between base
    > > system version and patch version.
    > >
    > > Please test, test, test. If I get enough positive feedback, I may be
    > > able to squeeze it into 7.1-RELEASE, but this might be hard.
    > >
    > > If you have any questions, please use mailing lists
    > > (freebsd-fs@FreeBSD.org would be the best).

    >
    > Is this supposed to help with memory pressure on i386, too? Or do the caveats
    > from the wiki still apply? I heard some anecdotal evidence that it would
    > indeed help.


    Yes, it should fix most if not all 'kmem_map too small' panics, at least
    from what I tried. Tunning kmem_size is still needed to get better
    performance.

    > Everybody, remember to use "patch -p0" - just bit me ... again.


    Grr, forgot to mention that, sorry.

    --
    Pawel Jakub Dawidek http://www.wheel.pl
    pjd@FreeBSD.org http://www.FreeBSD.org
    FreeBSD committer Am I Evil? Yes, I Am!

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.4 (FreeBSD)

    iD8DBQFIjYQ/ForvXbEpPzQRAomfAKDMoK0i912osVBIfbh6V1HUCbvP+gCfZj KN
    0kpFV9ndhQjhCGFMJ94J22s=
    =axux
    -----END PGP SIGNATURE-----


  5. Re: ZFS patches.

    On Mon, Jul 28, 2008 at 02:54:36PM +0200, Max Laier wrote:
    > On Monday 28 July 2008 10:33:03 Pawel Jakub Dawidek wrote:
    > > Yes, it should fix most if not all 'kmem_map too small' panics, at least
    > > from what I tried. Tunning kmem_size is still needed to get better
    > > performance.

    >
    > With the i386 default settings it was not too hard to get the attached panic.
    > Some cpdup and rm cycles of src and ports to a single disk zfs pool. With
    > 512M I haven't been able to kill it, yet.


    I was probably too optimistic. The default kmem_size is probably just
    too low. I'm quite sure it would be too low even for Solaris.

    --
    Pawel Jakub Dawidek http://www.wheel.pl
    pjd@FreeBSD.org http://www.FreeBSD.org
    FreeBSD committer Am I Evil? Yes, I Am!

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.4 (FreeBSD)

    iD8DBQFIjcInForvXbEpPzQRAml2AJsEuyTHdipqalyjOXKgso Yl/egUmgCgrhly
    fCZWeUt0yWgjylgRG7F1hOU=
    =OyQ3
    -----END PGP SIGNATURE-----


  6. Re: ZFS patches.

    So are we saying that i386 with a default kmem of 512MB has gotten
    psuedo stable with some load?

    On Mon, 2008-07-28 at 14:57 +0200, Pawel Jakub Dawidek wrote:
    > On Mon, Jul 28, 2008 at 02:54:36PM +0200, Max Laier wrote:
    > > On Monday 28 July 2008 10:33:03 Pawel Jakub Dawidek wrote:
    > > > Yes, it should fix most if not all 'kmem_map too small' panics, at least
    > > > from what I tried. Tunning kmem_size is still needed to get better
    > > > performance.

    > >
    > > With the i386 default settings it was not too hard to get the attached panic.
    > > Some cpdup and rm cycles of src and ports to a single disk zfs pool. With
    > > 512M I haven't been able to kill it, yet.

    >
    > I was probably too optimistic. The default kmem_size is probably just
    > too low. I'm quite sure it would be too low even for Solaris.
    >


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


  7. Re: ZFS patches.

    > I was probably too optimistic. The default kmem_size is probably just
    > too low. I'm quite sure it would be too low even for Solaris.


    In your estimation what is a good setting for kmem_size ?


    Sam Fourman Jr.
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...reebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"


  8. Re: ZFS patches.

    Hi,

    Pawel Jakub Dawidek wrote:
    > The patch above contains the most recent ZFS version that could be found
    > in OpenSolaris as of today. Apart for large amount of new functionality,
    > I belive there are many stability (and also performance) improvements
    > compared to the version from the base system.


    Thanks for the great work!

    > Please test, test, test. If I get enough positive feedback, I may be
    > able to squeeze it into 7.1-RELEASE, but this might be hard.


    I have a amd64 box with 8GB RAM running CURRENT-200806 snapshot. I get
    the latest version of the sources with csup, applied your patch and
    build the world/kernel.
    /usr/src and /usr/obj are located on a zfs file system. After "make
    installkernel" and reboot into single user mode I had to start the zfs
    file system but it failed:

    # fsck
    # mount -a
    # /etc/rc.d/hostid start
    Setting hostuuid: ...
    Setting hostid: ...
    # /etc/rc.d/zfs start
    lock order reversal:
    1st 0xffffff0004832620 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2053
    2nd 0xffffffff80b09da0 kernel linker (kernel linker) @
    /usr/src/sys/kern/kern_linker.c:693
    KDB: stack backtrace:
    db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
    witness_checkorder() at witness_checkorder+0x609
    _sx_xlock() at _sx_xlock+0x52
    linker_file_lookup_set() at linker_file_lookup_set+0xe1
    linker_file_register_sysctls() at linker_file_register_sysctls+0x20
    linker_load_module() at linker_load_module+0x919
    linker_load_dependencies() at linker_load_dependencies+0x1bc
    link_elf_load_file() at link_elf_load_file+0xa96
    linker_load_module() at linker_load_module+0x8cf
    kern_kldload() at kern_kldload+0xac
    kldload() at kldload+0x84
    syscall() at syscall+0x1bf
    Xfast_syscall() at Xfast_syscall+0xab
    --- syscall (304, FreeBSD ELF64, kldload), rip = 0x80068561c, rsp =
    0x7fffffffec88, rbp = 0 ---
    This module (opensolaris) contains code covered by the
    Common Development and Distribution License (CDDL)
    see http://opensolaris.org/os/licensing/...laris_license/
    WARNING: ZFS is considered to be an experimental feature in FreeBSD.
    ZFS filesystem version 11
    ZFS storage pool version 11
    internal error: out of memory
    internal error: out of memory
    internal error: out of memory
    internal error: out of memory

    Running "zpool list" shows no available pool and the "internal error:
    out of memory" error message.

    The same problem occurs in multi-user mode. loader.conf is set to:
    vm.kmem_size_max="2147483648"
    vm.kmem_size="2147483648"

    Increase/remove the kmem_size-values didn't change anything.

    To solve the problem I had to boot kernel.old and run make
    installworld/mergemaster. After rebooting with the new kernel the pool
    was available again and everything work without a problem.

    Did I do something wrong when I upgraded the server?

    Regards,
    Beat
    _______________________________________________
    freebsd-fs@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-fs
    To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"


  9. Re: ZFS patches.

    Antony Mawer wrote:
    > Ivan Voras wrote:


    >> I currently don't have high-end (4 CPU+) AMD64 machines to test, but
    >> with 1 CPU i386 virtual machine in VMWare, with 1 GB of memory,
    >> kmem_size=kmem_size_max=512M and no other tuning, with latest zpool
    >> format (11) it took about 15 minutes to get a "kmem_map too small"
    >> panic on a mixed load (buildkernel + blogbench + bonnie++).
    >>
    >> I've then tried the same load on the "real" hardware, 2 CPU, 2 GB
    >> memory, kmem_size=kmem_size_max=512M, and no other tuning, with the
    >> older zpool format (6) i get the same panic, though it takes about
    >> twice as long to happen.

    >
    > Have you tried tuning arc_max and/or monitoring vmstat -m to see what is
    > happening? What does arc_max get auto-tuned to at the moment (ie.
    > without manually specifying)?
    >
    > One of the things I recall reading that arc_max is more like a guide, as
    > some ZFS threads can exceed the max whilst other thread(s) go around
    > cleaning up and freeing memory once the limit is hit.
    >
    > Maybe some better smarts are needed in auto-tuning arc_max so that it
    > leaves more of a buffer zone than it does at the moment...?


    I think speculation in the same direction was discussed with the
    original port of ZFS - I don't know the details but if it arc_max could
    be better auto-tuned, I think it should be by now.

    I'm more concerned about the "quiet period" before the panic. I notice
    ZFS threads have the same priority (PRI field in top) as userland
    threads (e.g. 44, 55...), while GEOM threads have it different (-8). I
    don't have the McCusicks book about it so I don't know how priorities
    whould work, but is this situation OK?

    I will monitor vmstate -m if it will help Pawel. Should I?


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.5 (MingW32)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFIjmlzldnAQVacBcgRAvZnAJ4tBkASbaRrvFGqTDz/5d1f7PaTgQCdHTza
    D9T0FRoCMiScrv4wdKugRX8=
    =GSUG
    -----END PGP SIGNATURE-----


  10. Re: ZFS patches.

    May I ask whether these patches include the opensolaris crypto extension?
    http://opensolaris.org/os/project/zfs-crypto/


    On Sun, 27 Jul 2008 14:54:13 +0200
    Pawel Jakub Dawidek wrote:

    > Hi.
    >
    > http://people.freebsd.org/~pjd/patch...0727.patch.bz2
    >
    > The patch above contains the most recent ZFS version that could be found
    > in OpenSolaris as of today. Apart for large amount of new functionality,
    > I belive there are many stability (and also performance) improvements
    > compared to the version from the base system.
    >
    > Check out OpenSolaris website to find out the differences between base
    > system version and patch version.
    >
    > Please test, test, test. If I get enough positive feedback, I may be
    > able to squeeze it into 7.1-RELEASE, but this might be hard.
    >
    > If you have any questions, please use mailing lists
    > (freebsd-fs@FreeBSD.org would be the best).
    >
    > Thank you in advance!
    >



    --
    Üdvölettel,

    Czuczy Gergely
    Harmless Digital Bt
    mailto: gergely.czuczy@harmless.hu
    Tel: +36-30-9702963

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.3 (FreeBSD)

    iD8DBQFIkDgezrC0WyuMkpsRAvVQAJ9s1CNLxksi14DEv18XeT U6T52Y5wCgkAAs
    JLlNxnWT4Ee6IGXFri0krOk=
    =4hiX
    -----END PGP SIGNATURE-----


  11. Re: ZFS patches.

    On Monday 28 July 2008, John Nielsen wrote:
    > On Monday 28 July 2008, David Grochowski wrote:
    > > Hey,
    > >
    > > On Sun, Jul 27, 2008 at 11:24 PM, Adam McDougall

    >
    > wrote:
    > > > On Sun, Jul 27, 2008 at 02:54:13PM +0200, Pawel Jakub Dawidek wrote:
    > > > > Hi.
    > > > >
    > > > >
    > > > > http://people.freebsd.org/~pjd/patch...0727.patch.bz2
    > > >
    > > > Stop in /usr/src.

    > >
    > > I had the same issue. Try deleting
    > > "/usr/src/sys/cddl/compat/opensolaris/sys/acl.h" and
    > > "/usr/src/sys/cddl/compat/opensolaris/sys/callb.h" (make sure that
    > > these files have a length of zero first!). When patching, these files
    > > are supposed to be deleted, but were instead left as empty files.
    > > Since these files are included before the actual ones in
    > > "/usr/src/sys/cddl/contrib/opensolaris/uts/common/sys", this will
    > > cause a problem.
    > >
    > > Also, I would like to note that the patch has been working for me
    > > without any problems.

    >
    > Thanks for pointing this out David, I had been scratching my head too.
    > (Also thanks to those who posted reminders to use patch -p0).
    >
    > I'm now up and running with the patch and an upgraded zpool. No issues
    > thus far. I even tried to reproduce the UDP NFS write lockup issue I
    > reported recently and was unable to. Thanks PJD!


    I experienced a couple panics yesterday while working with some video files
    The panics didn't happen until after an hour or two of sustained activity
    (heavy reading and writing to/from multiple files about 2GB in size). The
    panic message (most recent) probably looks familiar:

    panic:kmem_malloc(65536): kmem_map too small: 757669888 total allocated

    This is on an i386 8-CURRENT box w/ the recent ZFS mega-patch applied:

    %uname -a
    FreeBSD stealth.jnielsen.net 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Mon Jul 28
    09:17:49 EDT 2008
    john@stealth.jnielsen.net:/usr/obj/usr/src8/src/sys/STEALTH i386

    %zfs upgrade
    This system is currently running ZFS filesystem version 3.
    All filesystems are formatted with the current version.

    %zpool upgrade
    This system is currently running ZFS pool version 11.
    All pools are formatted using this version.

    The box has 1.25 GB RAM. The kernel is compiled with KVA_PAGES=384 and
    vm.kmem_size and kmem_size_max are set to 768M.

    Since the last panic I have set vfs.zfs.arc_max to 160M and I haven't gotten
    another one, but I haven't had the same sustained activity since then
    either. I'll keep an eye on it.

    Just thought I'd send a report since I'm not sure if this is still expected
    behavior with the new patch. I am of course also open to tuning
    suggestions, though I have read the wiki and kept up on the mailing lists
    and am willing to experiment to see what ends up working best for this
    system.

    Thanks,

    JN
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...reebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"


  12. Re: ZFS patches

    Hi,

    Just let me intro this mail with a "Sorry for asking..."
    as I know the efforts already ongoing ar huge and I do
    respect this!

    But, here it is: any chances to see these patches on
    7-STABLE anytime... soon?

    I think there would be many more testers available (me included)
    than for HEAD. In my case, for example, all I could afford now
    is to set up a complete-test-only box with the HEAD code, which in
    turn wouldn't be a real test case as it would be "just" a test box
    for zfs.

    Whereas I could afford to test it in much more "real life"
    situation with 7-STABLE.
    My guess is that this would be the case for many others.

    The problem about HEAD is that there would be too many
    spots with potential problems (which ports work, which don't,
    scripts that might make 7-bound assumptions, etc..)
    so that I can't afford that for anything below "test only" boxes..

    Just experienced a deadlock again on 7-STABLE with zfs, that's
    why I'm refreshing this...

    Kudos && Regards,

    Lorenzo


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


  13. Re: ZFS patches


    It's still a bit too early for me to make any announcement about ZFS
    and stability on HEAD but I was having deadlocks on 7.0 every other
    day under my workload. I took the plunge and upgraded both my servers
    (which are now in production, BTW) to HEAD. I have one running HEAD
    without the latest patches and one with HEAD + patch and have not
    experienced a deadlock since the upgrade.

    FreeBSD back01.int.spry.com 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Fri
    Aug 15 16:42:36 PDT 2008 root@back01.int.spry.com:/usr/obj/usr/src/
    sys/BACK01 amd64

    FreeBSD back02.int.spry.com 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Wed
    Aug 13 13:57:19 PDT 2008 root@back02.int.spry.com:/usr/obj/usr/src/
    sys/BACK02-HEAD amd64

    It turns out that I disliked the known instability of ZFS and 7-STABLE
    than the unknown risks associated with HEAD. As always, YMMMV but
    since ZFS is still experimental, odds are good you'll have a better
    experience if you are willing to upgrade to -HEAD.

    Matt

    $ cat /boot/loader.conf
    vm.kmem_size="1536M"
    vm.kmem_size_max="1536M"
    vfs.zfs.arc_min="16M"
    vfs.zfs.arc_max="64M"
    vfs.zfs.prefetch_disable=1



    On Aug 21, 2008, at 5:44 AM, Lorenzo Perone wrote:

    > Hi,
    >
    > Just let me intro this mail with a "Sorry for asking..."
    > as I know the efforts already ongoing ar huge and I do
    > respect this!
    >
    > But, here it is: any chances to see these patches on
    > 7-STABLE anytime... soon?
    >
    > I think there would be many more testers available (me included)
    > than for HEAD. In my case, for example, all I could afford now
    > is to set up a complete-test-only box with the HEAD code, which in
    > turn wouldn't be a real test case as it would be "just" a test box
    > for zfs.
    >
    > Whereas I could afford to test it in much more "real life"
    > situation with 7-STABLE.
    > My guess is that this would be the case for many others.
    >
    > The problem about HEAD is that there would be too many
    > spots with potential problems (which ports work, which don't,
    > scripts that might make 7-bound assumptions, etc..)
    > so that I can't afford that for anything below "test only" boxes..
    >
    > Just experienced a deadlock again on 7-STABLE with zfs, that's
    > why I'm refreshing this...
    >
    > Kudos && Regards,
    >
    > Lorenzo
    >
    >
    > _______________________________________________
    > freebsd-fs@freebsd.org mailing list
    > http://lists.freebsd.org/mailman/listinfo/freebsd-fs
    > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"


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


  14. Re: ZFS patches

    My experience with ZFS and head is also early, but so far more
    successful
    than RELENG_7. RELENG_7 zfs worked fine for an unloaded system,
    but anything heavy (big tar xf) would freeze the computer in 60-120
    seconds
    with all variations of loader.conf settings recommended.

    With head from 8-23-08 and this patch I haven't been able to hang the
    system yet.

    I do, however, have trouble with interactive performance when copying
    a large file. All file
    reads on that FS hang until it completes. This is true under 7 and
    current. Any ideas?

    If in one window I do a "find ." and in another I copy a 300 Mb file,
    then find hangs for most of the copy time. Hardware affects then
    length of the hang. E.G. single USB drive=30 seconds, 4 drive raid-10
    3ware 8500 = 15 seconds, 4 drive areca raid-10 = 5 seconds.

    I'm concerned about production use on database and web servers having
    poor interactive performance when this happens.

  15. Re: ZFS patches.

    On Fri, Aug 29, 2008 at 03:29:58AM +0400, swell.k@gmail.com wrote:
    > (CC'ing Attilio, who made the commits)
    >
    > Pawel Jakub Dawidek writes:
    >
    > > Hi.
    > >
    > > http://people.freebsd.org/~pjd/patch...0727.patch.bz2
    > >
    > > The patch above contains the most recent ZFS version that could be found
    > > in OpenSolaris as of today. Apart for large amount of new functionality,
    > > I belive there are many stability (and also performance) improvements
    > > compared to the version from the base system.

    > [...]
    >
    > After r182371 and r182383 there are another three rejections. Namely
    > cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h.rej
    > sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_file.c.rej
    > sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_replay.c.rej
    > I'm attaching them in case someone has a quick fix or idea how
    > to solve them, especially regarding `+' lines.
    >
    > In the meantime I'm reverting them locally hoping it will not do any
    > harm to me. If this fails then I will stay with r182370 since I already
    > upgraded my pools to 11th version and can't go back easily.


    There are some rejections, I know, and I'm tracking everything in
    perforce. In the meantime there were two ZFS version bumps in
    OpenSOlaris (so I've 13 in perforce at the moment). I probably won't
    create new patch, but just commit what I've to HEAD. In the meantime
    also I fixes quite a few bugs, mostly reported by kris@.

    --
    Pawel Jakub Dawidek http://www.wheel.pl
    pjd@FreeBSD.org http://www.FreeBSD.org
    FreeBSD committer Am I Evil? Yes, I Am!

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.4 (FreeBSD)

    iD8DBQFIt6mZForvXbEpPzQRAtFsAKCgvO1v5SbOCtA3PghwlU pTyeYefACfbuHi
    rK7VZijb2t30gN9wugdPCDM=
    =fq2o
    -----END PGP SIGNATURE-----


  16. Re: ZFS patches.

    Hi Pawel,

    On 2008-Aug-28 20:47:30 +0000, Pawel Jakub Dawidek wrote:
    >On Fri, Aug 29, 2008 at 03:29:58AM +0400, swell.k@gmail.com wrote:
    >> (CC'ing Attilio, who made the commits)
    >>
    >> Pawel Jakub Dawidek writes:
    >>
    >> > Hi.
    >> >
    >> > http://people.freebsd.org/~pjd/patch...0727.patch.bz2
    >> >
    >> > The patch above contains the most recent ZFS version that could be found
    >> > in OpenSolaris as of today. Apart for large amount of new functionality,
    >> > I belive there are many stability (and also performance) improvements
    >> > compared to the version from the base system.

    >> [...]
    >>
    >> After r182371 and r182383 there are another three rejections. Namely
    >> cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h.rej
    >> sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_file.c.rej
    >> sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_replay.c.rej
    >> I'm attaching them in case someone has a quick fix or idea how
    >> to solve them, especially regarding `+' lines.
    >>
    >> In the meantime I'm reverting them locally hoping it will not do any
    >> harm to me. If this fails then I will stay with r182370 since I already
    >> upgraded my pools to 11th version and can't go back easily.

    >
    >There are some rejections, I know, and I'm tracking everything in
    >perforce. In the meantime there were two ZFS version bumps in
    >OpenSOlaris (so I've 13 in perforce at the moment). I probably won't
    >create new patch, but just commit what I've to HEAD. In the meantime
    >also I fixes quite a few bugs, mostly reported by kris@.


    It's now somewhat over two months later and the latest ZFS patchset
    still appears to be zfs_20080727.patch.bz2. Unfortunately, these
    patches no longer apply to -current (I tried working through the
    rejects but must have missed something because I wound up with an
    unkillable running process).

    Can you please give us an indication as to when we might expect to see
    either an updated set of ZFS patches (or, better, the patches committed
    to -current).

    --
    Peter Jeremy
    Please excuse any delays as the result of my ISP's inability to implement
    an MTA that is either RFC2821-compliant or matches their claimed behaviour.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.9 (FreeBSD)

    iEYEARECAAYFAkkLaAYACgkQ/opHv/APuIcqcQCeOIcBtNvpNjFJvDDn3Gh8xZEL
    I8sAoJ7JPIdL1pdaahcb4bO/i1dX7WSF
    =qouH
    -----END PGP SIGNATURE-----


  17. Re: ZFS patches.


    On 01.11.2008, at 02:39, Peter Jeremy wrote:

    > Can you please give us an indication as to when we might expect to see
    > either an updated set of ZFS patches (or, better, the patches
    > committed
    > to -current).


    Me too. ;-) I just want to second that request. While I'm also still
    desperately waiting for an update, basically all I'd like to see at
    this point is a rough schedule when I/we could expect all the recent
    changes in Perforce to be in CVS HEAD for testing.

    Cheers,

    Marcus

    --
    Marcus Mueller . . . crack-admin/coder ;-)
    Mulle kybernetiK . http://www.mulle-kybernetik.com
    Current projects: http://www.mulle-kybernetik.com/znek/


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


  18. RE: ZFS patches.


    >On 01.11.2008, at 02:39, Peter Jeremy wrote:
    >
    >> Can you please give us an indication as to when we might expect to see
    >> either an updated set of ZFS patches (or, better, the patches
    >> committed
    >> to -current).

    >
    >Me too. ;-) I just want to second that request. While I'm also still
    >desperately waiting for an update, basically all I'd like to see at
    >this point is a rough schedule when I/we could expect all the recent
    >changes in Perforce to be in CVS HEAD for testing.


    I'd like to 3rd this request. I'm running a -CURRENT system from August
    with the patches and upgraded
    ZPOOL/ZFS's. I'd like to get more recent on the system sources, but I know
    there are issues with the ZFS
    patch, and would love to see the schedule or a new patch against recent
    HEAD.

    Thanks!


    --
    Larry Rosenman http://www.lerctr.org/~ler
    Phone: +1 512-248-2683 E-Mail: ler@lerctr.org
    US Mail: 430 Valona Loop, Round Rock, TX 78681-3893




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


  19. Re: ZFS patches.

    2008/11/8 Larry Rosenman

    >
    > >On 01.11.2008, at 02:39, Peter Jeremy wrote:
    > >
    > >> Can you please give us an indication as to when we might expect to see
    > >> either an updated set of ZFS patches (or, better, the patches
    > >> committed
    > >> to -current).

    > >
    > >Me too. ;-) I just want to second that request. While I'm also still
    > >desperately waiting for an update, basically all I'd like to see at
    > >this point is a rough schedule when I/we could expect all the recent
    > >changes in Perforce to be in CVS HEAD for testing.

    >
    > I'd like to 3rd this request. I'm running a -CURRENT system from August
    > with the patches and upgraded
    > ZPOOL/ZFS's. I'd like to get more recent on the system sources, but I
    > know
    > there are issues with the ZFS
    > patch, and would love to see the schedule or a new patch against recent
    > HEAD.
    >
    > Thanks!
    >
    >
    > --
    > Larry Rosenman http://www.lerctr.org/~ler
    > Phone: +1 512-248-2683 E-Mail: ler@lerctr.org
    > US Mail: 430 Valona Loop, Round Rock, TX 78681-3893
    >
    >
    >
    >
    > _______________________________________________
    > freebsd-fs@freebsd.org mailing list
    > http://lists.freebsd.org/mailman/listinfo/freebsd-fs
    > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"
    >

    Hello,
    as I'm simple, I'd stick with commiting ZFS patches for start.
    Once in the tree, it's more "easy" from there.
    It's up to pjd and core to decide when, but it doesn't hurt ranting.
    Happy Sunday to all.
    _______________________________________________
    freebsd-fs@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-fs
    To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"


+ Reply to Thread