Date: Wed, 24 Mar 2010 11:07:57 -0700 From: Xin LI <delphij@gmail.com> To: Steve Pate <spate@mac.com> Cc: freebsd-fs@freebsd.org, Pawel Jakub Dawidek <pjd@freebsd.org>, Andriy Gapon <avg@icyb.net.ua> Subject: Re: ZFS and Deduplication? Message-ID: <a78074951003241107p2ed38541neb08350e148f09fc@mail.gmail.com> In-Reply-To: <2FF0A3E3-AF2F-4674-8648-FC01EC87445E@mac.com> References: <DFFEE631-BF1B-4C44-8B25-7C1EBE89BB2F@mac.com> <4BAA3E25.9040108@icyb.net.ua> <2FF0A3E3-AF2F-4674-8648-FC01EC87445E@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, Steve, On Wed, Mar 24, 2010 at 10:24 AM, Steve Pate <spate@mac.com> wrote: > I'm really not familiar with the FreeBSD development process so I apologi= ze if I'm asking questions which appear naive. > > We'd like to ship a FreeBSD-based product by early next year that contain= s ZFS with de-dup. From what I see, FreeBSD seems to be tracking Solaris in= terms of taking stable versions of ZFS. In other words, you're taking the = version of ZFS that will next move from Open Solaris to Solaris. Is that co= rrect? > > >From what I understand FreeBSD 8-STABLE includes ZFS version 14, which b= rings it to parity with Solaris 10. > > ZFS version 21 contains de-duplication so is quite a long way ahead of wh= ere FreeBSD is today. This implies that it will take quite some time for ZF= S + de-dupe to get into a stable version of FreeBSD. Correct? > > Now, if we were to port ZFS version 22 (or later) to FreeBSD 8.x (version= number TBD), how could we work with the FreeBSD team to get ZFS version 21= + back into a subsequent FreeBSD release? Pawel is working on porting the -HEAD ZFS version from OpenSolaris right no= w. For FreeBSD 8.x I think there are some things that we need to take into consideration. OpenSolaris generally strives to keep API/ABI stability but for ZFS management tools like zfs(1m) and friends this does not apply, e.g., the ioctl request structure changes from time to time. In the past we broke ABI across ZFS v6 -> v13 update. This basically means one will have to update kernel and userland at the same time, which would make the upgrade an one-way ticket (otherwise it would be impossible to do operations like zpool import once kernel is upgraded and restarted). I think, if we plan to MFC it we need to make some compatibility shims instead of using the current approach. Cheers, --=20 Xin LI <delphij@delphij.net> http://www.delphij.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a78074951003241107p2ed38541neb08350e148f09fc>