<http://sparcv9.blogspot.com/2011/12/solaris-11-illumos-and-source.html> If I "upgrade" ZFS to use the new features in Solaris 11 I will be unable> to import my pool using the free ZFS implementation that is available in > illumos based distributions >Is that accurate? I understand if the S11 version is ahead of illumos, of course I can''t use the same pools in both places, but that is the same problem as using an S11 pool on S10. The author is implying a much worse situation, that there are zfs "tracks" in addition to versions and that S11 is now on a different track and an S11 pool will not be usable elsewhere, "ever". I hope it''s just a misrepresentation. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20111227/ad585081/attachment.html>
On Tue, Dec 27, 2011 at 2:20 PM, Frank Cusack <frank at linetwo.net> wrote:> <http://sparcv9.blogspot.com/2011/12/solaris-11-illumos-and-source.html> > >> If I "upgrade" ZFS to use the new features in Solaris 11 I will be unable >> to import my pool using the free ZFS implementation that is available in >> illumos based distributions > > > Is that accurate?? I understand if the S11 version is ahead of illumos, of > course I can''t use the same pools in both places, but that is the same > problem as using an S11 pool on S10.? The author is implying a much worse > situation, that there are zfs "tracks" in addition to versions and that S11 > is now on a different track and an S11 pool will not be usable elsewhere, > "ever".? I hope it''s just a misrepresentation.Hard to say. Suppose Oracle releases no details on any additions to the on-disk ZFS format since build 147... then either the rest of the ZFS developer community forks for good, or they have to reverse engineer Oracle''s additions. Even if Oracle does release details on their additions, what if the external ZFS developer community disagrees vehemently with any of those? And what if the open source community adds extensions that Oracle never adopts? A fork is not yet a reality, but IMO it sure looks likely. Of course, you can still manage to have pools that will work on all implementations -- until the day that implementations start removing older formats anyways, which not only could happen, but I think will happen, though probably not until S10 is EOLed, and in any case probably not for a few years yet, likely not even within the next half decade. It''s hard to predict such things though, so take the above with some (or lots!) of salt. Nico --
On 12/27/11 09:20 PM, Frank Cusack wrote:> <http://sparcv9.blogspot.com/2011/12/solaris-11-illumos-and-source.html> > > If I "upgrade" ZFS to use the new features in Solaris 11 I will be > unable to import my pool using the free ZFS implementation that is > available in illumos based distributions > > > Is that accurate? I understand if the S11 version is ahead of > illumos, of course I can''t use the same pools in both places, but that > is the same problem as using an S11 pool on S10. The author is > implying a much worse situation, that there are zfs "tracks" in > addition to versions and that S11 is now on a different track and an > S11 pool will not be usable elsewhere, "ever". I hope it''s just a > misrepresentation.I used to have rpool from 2009.06 Opensolaris , updated over snv_134 to both Openindiana with Illumos and to the Solaris11 express in separate Boot environment, but at the same ZFS rpool. Since then, Oracle removed both pkg.opensolaris.org/release and /dev and also seems that there is no Solaris11 express IPS publisher to be found anymore. So, one could use pkg.openindiana.org/legacy to update to snv_134 (Not the Oracle''s snv_134b needed to S11Express upgrade) and to upgrade to Openindiana latest /dev as described on openindiana.org Wiki. But for Updating to snv_134b fro Oracle and Solaris11 Express, prior to updating to Solaris11 on the same rpool, one would need to download and activate local IPS repository of both of them and install from there, since Oracle pulled the plug from both, most probably to actually stop just that thing: Ability to have Openindiana and Solaris11 on the same rpool, upgraded from snv_134 , because S11 ZFS is closed source and "newer" version number, and therefore not usable for any implementation but Oracle''s (including Illumos, Zfs-fuse, ZfsonLinux and FreeBSD implementations) Recent S11 source code leak might help as a blueprint for implementing maybe compatible implementations in other OS''es but Oracle, but it needs to be re-written, and not copied due to Oracle''s copyright. So it is possible to have S11 and Openindiana/Illumos on same rpool. Just jou need both snv_134b Opensolaris and S11Express IPS publisher to update from. You can put them up from repository archives and if you do, share a cookbook for it, OK? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20111227/dfbf87ae/attachment.html>
On Dec 27, 2011, at 9:20 PM, Frank Cusack wrote:> <http://sparcv9.blogspot.com/2011/12/solaris-11-illumos-and-source.html> > > If I "upgrade" ZFS to use the new features in Solaris 11 I will be unable to import my pool using the free ZFS implementation that is available in illumos based distributions > > Is that accurate? I understand if the S11 version is ahead of illumos, of course I can''t use the same pools in both places, but that is the same problem as using an S11 pool on S10. The author is implying a much worse situation, that there are zfs "tracks" in addition to versions and that S11 is now on a different track and an S11 pool will not be usable elsewhere, "ever". I hope it''s just a misrepresentation.I think the author has a valid point ;) I probably should have written zpools instead of ZFS in that sentence. It is same as always with different pool version and features, but in this case we don''t now if they will be implemented and implemented in the same way outside of Oracle after zpool version 28 since we do not have the source and Oracle does''t want to play with us. Regards Henrik http://sparcv9.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20111228/a41c510f/attachment.html>
So with a de facto fork (illumos) now in place, is it possible that two zpools will report the same version yet be incompatible across implementations? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20111227/9bff0129/attachment.html>
On Tue, 27 Dec 2011, Frank Cusack wrote:> So with a de facto fork (illumos) now in place, is it possible that two > zpools will report the same version yet be incompatible across > implementations?I hope not. :-( ISTR some super-secret, behind-closed-doors ZFS steering commitee being established to try to avoid such a nightmare scenario... -- Rich Teer, Publisher Vinylphile Magazine . * * . * .* . . * . .* * . . /\ ( . . * . . / .\ . * . .*. / * \ . . . /* o \ . * ''''''||'''''' . www.vinylphilemag.com ******************
On Tue, Dec 27, 2011 at 8:44 PM, Frank Cusack <frank at linetwo.net> wrote:> So with a de facto fork (illumos) now in place, is it possible that two > zpools will report the same version yet be incompatible across > implementations?Not likely: the Illumos community has developed a method for managing ZFS extensions in a way other than linear chronology. Nico --
On Tue, Dec 27, 2011 at 9:34 PM, Nico Williams <nico at cryptonector.com>wrote:> On Tue, Dec 27, 2011 at 8:44 PM, Frank Cusack <frank at linetwo.net> wrote: > > So with a de facto fork (illumos) now in place, is it possible that two > > zpools will report the same version yet be incompatible across > > implementations? > > Not likely: the Illumos community has developed a method for managing > ZFS extensions in a way other than linear chronology. > > Nico > >I''m not sure that answer is helpful. If they aren''t revving the ID when features are added, how exactly is someone supposed to know the feature status of their release? I know they were trying to compartmentalize features, but feature number is the quickest and easiest way to differentiate functionality. If you have to filter through a list of potentially hundreds of features to determine compatibility, that''s going to be a nightmare long-term (which is why most products use a version number in the first place). --Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20111227/4fe981bf/attachment.html>
On Dec 27, 2011, at 7:46 PM, Tim Cook wrote:> On Tue, Dec 27, 2011 at 9:34 PM, Nico Williams <nico at cryptonector.com> wrote: > On Tue, Dec 27, 2011 at 8:44 PM, Frank Cusack <frank at linetwo.net> wrote: > > So with a de facto fork (illumos) now in place, is it possible that two > > zpools will report the same version yet be incompatible across > > implementations?This was already broken by Sun/Oracle when the deduplication feature was not backported to Solaris 10. If you are running Solaris 10, then zpool version 29 features are not implemented.> > Not likely: the Illumos community has developed a method for managing > ZFS extensions in a way other than linear chronology.This goes beyond the illumos community.> I''m not sure that answer is helpful. If they aren''t revving the ID when features are added, how exactly is someone supposed to know the feature status of their release? I know they were trying to compartmentalize features, but feature number is the quickest and easiest way to differentiate functionality. If you have to filter through a list of potentially hundreds of features to determine compatibility, that''s going to be a nightmare long-term (which is why most products use a version number in the first place).This was discussed on the list last May. http://mail.opensolaris.org/pipermail/zfs-discuss/2011-May/048514.html On Dec 27, 2011, at 6:57 PM, Rich Teer wrote:> On Tue, 27 Dec 2011, Frank Cusack wrote: > >> So with a de facto fork (illumos) now in place, is it possible that two >> zpools will report the same version yet be incompatible across >> implementations?As shown above, this is already the case between Solaris 10 and 11.> I hope not. :-(I agree, it is unfortunate.> ISTR some super-secret, behind-closed-doors ZFS steering commitee being > established to try to avoid such a nightmare scenario?I wouldn''t refer to the Oracle ZFS team in that way! There are lots of good folks striving to do the right thing there. Oh, perhaps you are referring to the ZFS working group? If so, there are no super- secrets there. As the above URL states, The community of developers working on ZFS continues to grow, as does the diversity of companies betting big on ZFS. We wanted a forum for these developers to coordinate their efforts and exchange ideas. The ZFS working group was formed to coordinate these development efforts. The working group encourages new membership. In order to maintain the group''s focus on ZFS development, candidates should demonstrate significant and ongoing contribution to ZFS. Note that the ZFS working group members represent several OSes beyond the SunOS-derived OSes. If you are interested in porting ZFS to a new OS, then the ZFS working group is interested in providing support. For the truly open source illumos project, many of the former Sun ZFS team regularly contribute to ZFS through the illumos developer community. illumos-developer lists and archives are available at https://www.illumos.org/projects/site/wiki/Mailing_Lists -- richard -- ZFS and performance consulting http://www.RichardElling.com
Richard Elling wrote:>?many of the former Sun ZFS team? > regularly contribute to ZFS through the illumos developer community. ?Does this mean that if they provide a bug fix via illumos then the fix won''t make it into the Oracle code? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20111229/192e70a9/attachment.html>
On Thu, Dec 29, 2011 at 2:06 PM, sol <arb at yahoo.com> wrote:> Richard Elling wrote: >>?many of the former Sun ZFS team >> regularly contribute to ZFS through the illumos developer community. > > Does this mean that if they provide a bug fix via illumos then the fix won''t > make it into the Oracle code?If you''re an Oracle customer you should report any ZFS bugs you find to Oracle if you want fixes in Solaris. You may want to (and I encourage you to) report such bugs to Illumos if at all possible (i.e., unless your agreement with Oracle or your employer''s policies somehow prevent you from doing so). The following is complete speculation. Take it with salt. With reference to your question, it may mean that Oracle''s ZFS team would have to come up with their own fixes to the same bugs. Oracle''s legal department would almost certainly have to clear the copying of any non-trivial/obvious fix from Illumos into Oracle''s ON tree. And if taking a fix from Illumos were to require opening the affected files (because they are under CDDL in Illumos) then executive management approval would also be required. But the most likely case is that the issue simply wouldn''t come up in the first place because Oracle''s ZFS team would almost certainly ignore the Illumos repository (perhaps not the Illumos bug tracker, but probably that too) as that''s simply the easiest way for them to avoid legal messes. Think about it. Besides, I suspect that from Oracle''s point of view what matters are bug reports by Oracle customers to Oracle, so if a bug fixed in Illumos is never reported to Oracle by a customer, it would likely never get fixed in Solaris either except by accident, as a result of another change. Also, the Oracle ZFS team is not exactly devoid of clue, even with the departures from it to date. I suspect they will be able to fix bugs in Oracle''s ZFS and completely independently of the open ZFS community, even if it means duplicating effort. That said, Illumos is a fork of OpenSolaris, and as such it and Solaris will necessarily diverge as at least one of the two (and probably both, for a while) gets plenty of bug fixes and enhancements. This is a good thing, not a bad thing, at least for now. Nico --
On Dec 29, 2011, at 1:29 PM, Nico Williams wrote:> On Thu, Dec 29, 2011 at 2:06 PM, sol <arb at yahoo.com> wrote: >> Richard Elling wrote: >>> many of the former Sun ZFS team >>> regularly contribute to ZFS through the illumos developer community. >> >> Does this mean that if they provide a bug fix via illumos then the fix won''t >> make it into the Oracle code?I can''t speak for Oracle, but I think the entire ZFS community benefits when bugs are fixed. Squeaky wheels get the grease, so squeak often.> If you''re an Oracle customer you should report any ZFS bugs you find > to Oracle if you want fixes in Solaris. You may want to (and I > encourage you to) report such bugs to Illumos if at all possible > (i.e., unless your agreement with Oracle or your employer''s policies > somehow prevent you from doing so).+1> The following is complete speculation. Take it with salt. > > With reference to your question, it may mean that Oracle''s ZFS team > would have to come up with their own fixes to the same bugs. Oracle''s > legal department would almost certainly have to clear the copying of > any non-trivial/obvious fix from Illumos into Oracle''s ON tree. And > if taking a fix from Illumos were to require opening the affected > files (because they are under CDDL in Illumos) then executive > management approval would also be required. But the most likely case > is that the issue simply wouldn''t come up in the first place because > Oracle''s ZFS team would almost certainly ignore the Illumos repository > (perhaps not the Illumos bug tracker, but probably that too) as that''s > simply the easiest way for them to avoid legal messes. Think about > it. Besides, I suspect that from Oracle''s point of view what matters > are bug reports by Oracle customers to Oracle, so if a bug fixed in > Illumos is never reported to Oracle by a customer, it would likely > never get fixed in Solaris either except by accident, as a result of > another change. > > Also, the Oracle ZFS team is not exactly devoid of clue, even with the > departures from it to date. I suspect they will be able to fix bugs > in Oracle''s ZFS and completely independently of the open ZFS > community, even if it means duplicating effort.Yes, Oracle continues to develop and sustain its Solaris products. This can only be viewed as a good thing.> That said, Illumos is a fork of OpenSolaris, and as such it and > Solaris will necessarily diverge as at least one of the two (and > probably both, for a while) gets plenty of bug fixes and enhancements. > This is a good thing, not a bad thing, at least for now.Evolution continues, despite the rhetoric from the pulpit :-) -- richard -- ZFS and performance consulting http://www.RichardElling.com illumos meetup, Jan 10, 2012, Menlo Park, CA http://www.meetup.com/illumos-User-Group/events/41665962/
On 12/28/11 06:27, Richard Elling wrote:> On Dec 27, 2011, at 7:46 PM, Tim Cook wrote: >> On Tue, Dec 27, 2011 at 9:34 PM, Nico Williams<nico at cryptonector.com> wrote: >> On Tue, Dec 27, 2011 at 8:44 PM, Frank Cusack<frank at linetwo.net> wrote: >>> So with a de facto fork (illumos) now in place, is it possible that two >>> zpools will report the same version yet be incompatible across >>> implementations? > > This was already broken by Sun/Oracle when the deduplication feature was not > backported to Solaris 10. If you are running Solaris 10, then zpool version 29 features > are not implemented.Solaris 10 does have some deduplication support, it can import and read datasets in a deduped pool just fine. You can''t enable dedup on a dataset and any writes won''t dedup they will "rehydrate". So it is more like partial dedup support rather than it not being there at all. -- Darren J Moffat
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3 Jan 12, at 04:22 , Darren J Moffat wrote:> On 12/28/11 06:27, Richard Elling wrote: >> On Dec 27, 2011, at 7:46 PM, Tim Cook wrote: >>> On Tue, Dec 27, 2011 at 9:34 PM, Nico Williams<nico at cryptonector.com> wrote: >>> On Tue, Dec 27, 2011 at 8:44 PM, Frank Cusack<frank at linetwo.net> wrote: >>>> So with a de facto fork (illumos) now in place, is it possible that two >>>> zpools will report the same version yet be incompatible across >>>> implementations? >> >> This was already broken by Sun/Oracle when the deduplication feature was not >> backported to Solaris 10. If you are running Solaris 10, then zpool version 29 features >> are not implemented. > > Solaris 10 does have some deduplication support, it can import and read datasets in a deduped pool just fine. You can''t enable dedup on a dataset and any writes won''t dedup they will "rehydrate". > > So it is more like partial dedup support rather than it not being there at all."rehydrate"??? Is it instant or freeze dried? Mike - --- Michael Sullivan mps at axsh.us http://www.axsh.us/ Phone: +1-662-259-8888 Mobile: +1-662-202-7716 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJPAuOzAAoJEPFdIteZcPZgn7QQAI0nq500qymcpuTreoPpDHIL vvMtRS4/VoOxmHbu2wJT9GO21f4JC3CCzFRHl8t6NkAK5vi9cuNUx1IGjDjlZAqG Vp3H2DmtuHVHsPiAGB4J7b3zI4U8IL5tPhgbEcg5kkiTqBjMOCTdg1ibRz7ovf9Y aDmplOD1d2UN5il6FEs3ZEojHslb4yoRajd5HgyjibF6sdC1leKcAFaUOg9q0t/s 40Ckzw6G4RC5mCb6WHK+a4WXPUMG4uPryIRl4F4jxqrMCSw/rIUHa1slVcagu1gO wft+P7Y922SPnClMHhDufIGGKrqvJaOriYU+1ZXVoil18BaauboVn1/PEtlDOF57 vy0jOiC/DVICvk/AzzKfQxlO9YFhu4RInc27B2Ut4pCmXLeDDJpy5QXge+AZBM6K Q2dPJJ3ZNii4JYsTfIufMzWjBwBMhUgkbbK5kbdNyuIptg/ueHOKOf+v9gSkqCGC CjWrqtchtBSHa5Vw1JjMbKR5Y2qNzH+YuYICFgnYvJbZ31WO8TdzRL+M8PnuJRE3 WJDKs0TmSStYiuGZ1jf1oA3SJ1gcok47rYueSGKcmMSfhHfw3zeB0JpHLVQaCG2j k2CwfwGskSs1FvgHR+YbCCne5KXwk5PzqCvd5IGH7GZyEOJLtW29MjW5d2TazSzr 3u01cKzStpyXPaxj6+cD =SLu1 -----END PGP SIGNATURE-----
> if a bug fixed in?Illumos is never reported to Oracle by a customer, > it would likely?never get fixed in Solaris either:-( I would have liked to think that there was some good-will between the ex- and current-members of the zfs team, in the sense that the people who created zfs but then left Oracle still care about it enough to want the Oracle version to be as bug-free as possible. (Obviously I don''t expect this to be the case for developers of all software but I think filesystem developers are a special breed!)
On Jan 5, 2012, at 6:53 AM, sol wrote:>> if a bug fixed in Illumos is never reported to Oracle by a customer, >> it would likely never get fixed in Solaris either > > > :-( > > I would have liked to think that there was some good-will between the ex- and current-members of the zfs team, in the sense that the people who created zfs but then left Oracle still care about it enough to want the Oracle version to be as bug-free as possible.There is good-will between the developers. And the ZFS working group has representatives currently employed by Oracle. However, Oracle is a lawnmower. http://www.youtube.com/watch?v=-zRN7XLCRhc> > (Obviously I don''t expect this to be the case for developers of all software but I think filesystem developers are a special breed!)They are! And there are a lot of really cool things happening in the wild as well as behind Oracle''s closed doors. -- richard -- ZFS and performance consulting http://www.RichardElling.com illumos meetup, Jan 10, 2012, Menlo Park, CA http://www.meetup.com/illumos-User-Group/events/41665962/
On Thu, Jan 5, 2012 at 8:53 AM, sol <arb at yahoo.com> wrote:>> if a bug fixed in?Illumos is never reported to Oracle by a customer, >> it would likely?never get fixed in Solaris either > > :-( > > I would have liked to think that there was some good-will between the ex- and current-members of the zfs team, in the sense that the people who created zfs but then left Oracle still care about it enough to want the Oracle version to be as bug-free as possible.My intention was to encourage users to report bugs to both, Oracle and Illumos. It''s possible that Oracle engineers pay attention to the Illumos bug database, but I expect that for legal reasons the will not look at Illumos code that has any new copyright notices relative to Oracle code. The simplest way for Oracle engineers to avoid all possible legal problems is to simply ignore at least the Illumos source repositories, possibly more. I''m speculating, sure; I might be wrong. As for good will, I''m certain that there is, at least at the engineer level, and probably beyond. But that doesn''t mean that there will be bug parity, much less feature parity. Nico --
On Thu, Jan 5, 2012 at 9:32 AM, Richard Elling <richard.elling at gmail.com>wrote:> On Jan 5, 2012, at 6:53 AM, sol wrote: > >> if a bug fixed in Illumos is never reported to Oracle by a customer, > >> it would likely never get fixed in Solaris either > > > > > > :-( > > > > I would have liked to think that there was some good-will between the > ex- and current-members of the zfs team, in the sense that the people who > created zfs but then left Oracle still care about it enough to want the > Oracle version to be as bug-free as possible. > > There is good-will between the developers. And the ZFS working group has > representatives > currently employed by Oracle. However, Oracle is a lawnmower. > http://www.youtube.com/watch?v=-zRN7XLCRhc > > > > > (Obviously I don''t expect this to be the case for developers of all > software but I think filesystem developers are a special breed!) > > They are! And there are a lot of really cool things happening in the wild > as well as behind > Oracle''s closed doors. > -- richard > > -- > > ZFS and performance consulting > http://www.RichardElling.com > illumos meetup, Jan 10, 2012, Menlo Park, CA > http://www.meetup.com/illumos-User-Group/events/41665962/ > > >Speaking of illumos, what exactly is the deal with the zfs discuss mailing list? There''s all of 3 posts that show up for all of 2011. Am I missing something, or is there just that little traction currently? http://www.listbox.com/member/archive/182191/sort/time_rev/ --Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20120105/7a064758/attachment.html>
On Jan 5, 2012, at 10:19 AM, Tim Cook wrote:> Speaking of illumos, what exactly is the deal with the zfs discuss mailing list? There''s all of 3 posts that show up for all of 2011. Am I missing something, or is there just that little traction currently? > http://www.listbox.com/member/archive/182191/sort/time_rev/AIUI, that forum was created to solve the problem of opensolaris.org disappearing off the face of the planet -- a real fear at the time, since Oracle had recently assassinated everything related to the name "opensolaris." Fortunately, opensolaris.org remains, so there never was a mass migration of zfs-discuss. -- richard -- ZFS and performance consulting http://www.RichardElling.com illumos meetup, Jan 10, 2012, Menlo Park, CA http://www.meetup.com/illumos-User-Group/events/41665962/
On Thu, Jan 5, 2012 at 6:53 AM, sol <arb at yahoo.com> wrote:> > I would have liked to think that there was some good-will between the ex- > and current-members of the zfs team, in the sense that the people who > created zfs but then left Oracle still care about it enough to want the > Oracle version to be as bug-free as possible. >There is plenty of good will between everyone who''s worked on ZFS -- current Oracle employees, former employees, and those never employed by Oracle. We would all like to see all implementations of ZFS be the highest quality possible. I''d like to think that we all try to achieve that to the extent that it is possible within our corporate priorities. --matt -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20120116/adddb0e9/attachment.html>
Thanks for that, Matt, very reassuring ?:-)>________________________________ > There is plenty of good will between everyone who''s worked on ZFS -- current Oracle employees, former employees, and those never employed by Oracle. ?We would all like to see all implementations of ZFS be the highest quality possible. ?I''d like to think that we all try to achieve that to the extent that it is possible within our corporate priorities. > > >--matt-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20120116/76174f18/attachment.html>
2012-01-16 23:29, Matthew Ahrens wrote:> On Thu, Jan 5, 2012 at 6:53 AM, sol <arb at yahoo.com > <mailto:arb at yahoo.com>> wrote: > > > I would have liked to think that there was some good-will between > the ex- and current-members of the zfs team, in the sense that the > people who created zfs but then left Oracle still care about it > enough to want the Oracle version to be as bug-free as possible. > > > There is plenty of good will between everyone who''s worked on ZFS -- > current Oracle employees, former employees, and those never employed by > Oracle. We would all like to see all implementations of ZFS be the > highest quality possible. I''d like to think that we all try to achieve > that to the extent that it is possible within our corporate priorities.Thank you for shedding some light of hope. ;) //Jim Klimov
Hi I''ve just tried to use illumos (151a5) ?import a pool created on solaris (11.1) but it failed with an error about the pool being incompatible. Are we now at the stage where the two prongs of the zfs fork are pointing in incompatible directions?>________________________________ > From: Matthew Ahrens <mahrens at delphix.com> >On Thu, Jan 5, 2012 at 6:53 AM, sol <arb at yahoo.com>wrote: > > >>I would have liked to think that there was some good-will between the ex- and current-members of the zfs team, in the sense that the people who created zfs but then left Oracle still care about it enough to want the Oracle version to be as bug-free as possible.>> > > >There is plenty of good will between everyone who''s worked on ZFS -- current Oracle employees, former employees, and those never employed by Oracle. ?We would all like to see all implementations of ZFS be the highest quality possible. ?I''d like to think that we all try to achieve that to the extent that it is possible within our corporate priorities.-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20121213/0db650da/attachment.html>
Oracle effectively forked ZFS with the release of Solaris 11 by not open-sourcing any of the ZFS code. Solaris 11 includes ZFSv31 or higher. The last open-source release of ZFS was ZFSv28. Thus, if you create a pool on Solaris 11+ that you want to import on other systems, you have to manually tell it to create a ZFSv28 pool, and not use the defaults. On Thu, Dec 13, 2012 at 8:14 AM, sol <arb at yahoo.com> wrote:> Hi > > I''ve just tried to use illumos (151a5) import a pool created on solaris > (11.1) but it failed with an error about the pool being incompatible. > > Are we now at the stage where the two prongs of the zfs fork are pointing > in incompatible directions? > > ------------------------------ > *From:* Matthew Ahrens <mahrens at delphix.com> > On Thu, Jan 5, 2012 at 6:53 AM, sol <arb at yahoo.com> wrote: > > > I would have liked to think that there was some good-will between the ex- > and current-members of the zfs team, in the sense that the people who > created zfs but then left Oracle still care about it enough to want the > Oracle version to be as bug-free as possible. > > > There is plenty of good will between everyone who''s worked on ZFS -- > current Oracle employees, former employees, and those never employed by > Oracle. We would all like to see all implementations of ZFS be the highest > quality possible. I''d like to think that we all try to achieve that to the > extent that it is possible within our corporate priorities. > > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > >-- Freddie Cash fjwcash at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20121213/3b26bdbf/attachment-0001.html>
Hi, On Thu, Dec 13, 2012 at 9:14 AM, sol <arb at yahoo.com> wrote:> Hi > > I''ve just tried to use illumos (151a5) import a pool created on solaris > (11.1) but it failed with an error about the pool being incompatible. > > Are we now at the stage where the two prongs of the zfs fork are pointing in > incompatible directions?Yes, that is correct. The last version of Solaris with source code used zpool version 28. This is the last version that is readable by non-Solaris operating systems FreeBSD, GNU/Linux, but also OpenIndiana. The filesystem, "zfs", is technically at the same version, but you can''t access it if you can''t access the pool :-). If you want to access the data now, your only option is to use Solaris to read it, and copy it over (eg. with zfs send | recv) onto a pool created with version 28. Jan
That is a touch misleading. This has always been the case since S10u2. You have to create the pool AND the file systems at the oldest versions you want to support. I maintain a table of pool and version numbers on my blog (blogs.oracle. com/bobn) for this very purpose. I got lazy the other day and made this mistake between 11ga and 11.1. Watch the ZFS send approach because you might be sending a newer file system version than is supported. Yes, I''ve done that too :) Bob Sent from my iPhone On Dec 13, 2012, at 10:47 AM, Jan Owoc <jsowoc at gmail.com> wrote:> Hi, > > On Thu, Dec 13, 2012 at 9:14 AM, sol <arb at yahoo.com> wrote: >> Hi >> >> I''ve just tried to use illumos (151a5) import a pool created on solaris >> (11.1) but it failed with an error about the pool being incompatible. >> >> Are we now at the stage where the two prongs of the zfs fork are pointing in >> incompatible directions? > > Yes, that is correct. The last version of Solaris with source code > used zpool version 28. This is the last version that is readable by > non-Solaris operating systems FreeBSD, GNU/Linux, but also > OpenIndiana. The filesystem, "zfs", is technically at the same > version, but you can''t access it if you can''t access the pool :-). > > If you want to access the data now, your only option is to use Solaris > to read it, and copy it over (eg. with zfs send | recv) onto a pool > created with version 28. > > Jan > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
On Thu, Dec 13, 2012 at 11:44 AM, Bob Netherton <bob.netherton at gmail.com> wrote:> On Dec 13, 2012, at 10:47 AM, Jan Owoc <jsowoc at gmail.com> wrote: >> Yes, that is correct. The last version of Solaris with source code >> used zpool version 28. This is the last version that is readable by >> non-Solaris operating systems FreeBSD, GNU/Linux, but also >> OpenIndiana. The filesystem, "zfs", is technically at the same >> version, but you can''t access it if you can''t access the pool :-). > > That is a touch misleading. This has always been the case since S10u2. You have to create the pool AND the file systems at the oldest versions you want to support. > > I maintain a table of pool and version numbers on my blog (blogs.oracle. com/bobn) for this very purpose. I got lazy the other day and made this mistake between 11ga and 11.1. > > Watch the ZFS send approach because you might be sending a newer file system version than is supported. Yes, I''ve done that too :)Bob, you are correct. There is now a new version of "zfs" in Solaris 11.1. I assume it''s incompatible with the previous version: http://docs.oracle.com/cd/E26502_01/html/E29007/gjxik.html#scrolltoc Any suggestions how to help OP read his data on anything but Solaris 11.1 or migrate it "back" a version? Jan
At this point, the only thing would be to use 11.1 to create a new pool at 151''s version (-o version=) and top level dataset (-O version=). Recreate the file system hierarchy and do something like an rsync. I don''t think there is anything more elegant, I''m afraid. That''s what I did yesterday :) Bob Sent from my iPhone On Dec 13, 2012, at 12:54 PM, Jan Owoc <jsowoc at gmail.com> wrote:> On Thu, Dec 13, 2012 at 11:44 AM, Bob Netherton <bob.netherton at gmail.com> wrote: >> On Dec 13, 2012, at 10:47 AM, Jan Owoc <jsowoc at gmail.com> wrote: >>> Yes, that is correct. The last version of Solaris with source code >>> used zpool version 28. This is the last version that is readable by >>> non-Solaris operating systems FreeBSD, GNU/Linux, but also >>> OpenIndiana. The filesystem, "zfs", is technically at the same >>> version, but you can''t access it if you can''t access the pool :-). >> >> That is a touch misleading. This has always been the case since S10u2. You have to create the pool AND the file systems at the oldest versions you want to support. >> >> I maintain a table of pool and version numbers on my blog (blogs.oracle. com/bobn) for this very purpose. I got lazy the other day and made this mistake between 11ga and 11.1. >> >> Watch the ZFS send approach because you might be sending a newer file system version than is supported. Yes, I''ve done that too :) > > Bob, you are correct. There is now a new version of "zfs" in Solaris > 11.1. I assume it''s incompatible with the previous version: > http://docs.oracle.com/cd/E26502_01/html/E29007/gjxik.html#scrolltoc > > Any suggestions how to help OP read his data on anything but Solaris > 11.1 or migrate it "back" a version? > > Jan
Perhaps slightly elegant, you can do the new pool/rsync thing on the 11.1 live CD so you don''t actually have to stand up a new system to do this. Assuming this is x86 and VirtualBox works on Illumos, you could fire up a VM to do this as well. Bob Sent from my iPhone On Dec 13, 2012, at 12:54 PM, Jan Owoc <jsowoc at gmail.com> wrote:> On Thu, Dec 13, 2012 at 11:44 AM, Bob Netherton <bob.netherton at gmail.com> wrote: >> On Dec 13, 2012, at 10:47 AM, Jan Owoc <jsowoc at gmail.com> wrote: >>> Yes, that is correct. The last version of Solaris with source code >>> used zpool version 28. This is the last version that is readable by >>> non-Solaris operating systems FreeBSD, GNU/Linux, but also >>> OpenIndiana. The filesystem, "zfs", is technically at the same >>> version, but you can''t access it if you can''t access the pool :-). >> >> That is a touch misleading. This has always been the case since S10u2. You have to create the pool AND the file systems at the oldest versions you want to support. >> >> I maintain a table of pool and version numbers on my blog (blogs.oracle. com/bobn) for this very purpose. I got lazy the other day and made this mistake between 11ga and 11.1. >> >> Watch the ZFS send approach because you might be sending a newer file system version than is supported. Yes, I''ve done that too :) > > Bob, you are correct. There is now a new version of "zfs" in Solaris > 11.1. I assume it''s incompatible with the previous version: > http://docs.oracle.com/cd/E26502_01/html/E29007/gjxik.html#scrolltoc > > Any suggestions how to help OP read his data on anything but Solaris > 11.1 or migrate it "back" a version? > > Jan
On 13 December, 2012 - Jan Owoc sent me these 1,0K bytes:> Hi, > > On Thu, Dec 13, 2012 at 9:14 AM, sol <arb at yahoo.com> wrote: > > Hi > > > > I''ve just tried to use illumos (151a5) import a pool created on solaris > > (11.1) but it failed with an error about the pool being incompatible. > > > > Are we now at the stage where the two prongs of the zfs fork are pointing in > > incompatible directions? > > Yes, that is correct. The last version of Solaris with source code > used zpool version 28. This is the last version that is readable by > non-Solaris operating systems FreeBSD, GNU/Linux, but also > OpenIndiana. The filesystem, "zfs", is technically at the same > version, but you can''t access it if you can''t access the pool :-).zfs version is bumped to 6 too in s11.1: The following filesystem versions are supported: VER DESCRIPTION --- -------------------------------------------------------- 1 Initial ZFS filesystem version 2 Enhanced directory entries 3 Case insensitive and SMB credentials support 4 userquota, groupquota properties 5 System attributes 6 Multilevel file system support Pool version is upped as well: 29 RAID-Z/mirror hybrid allocator 30 Encryption 31 Improved ''zfs list'' performance 32 One MB blocksize 33 Improved share support 34 Sharing with inheritance> If you want to access the data now, your only option is to use Solaris > to read it, and copy it over (eg. with zfs send | recv) onto a pool > created with version 28. > > Jan > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss/Tomas -- Tomas Forsman, stric at acc.umu.se, http://www.acc.umu.se/~stric/ |- Student at Computing Science, University of Ume? `- Sysadmin at {cs,acc}.umu.se
Edward Ned Harvey (opensolarisisdeadlongliveopensolaris)
2012-Dec-14 16:07 UTC
[zfs-discuss] S11 vs illumos zfs compatiblity
> From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss- > bounces at opensolaris.org] On Behalf Of Bob Netherton > > At this point, the only thing would be to use 11.1 to create a new pool at 151''s > version (-o version=) and top level dataset (-O version=). Recreate the file > system hierarchy and do something like an rsync. I don''t think there is > anything more elegant, I''m afraid.Is that right? You can''t use zfs send | zfs receive to send from a newer version and receive on an older version?
On 12/14/12 10:07 AM, Edward Ned Harvey (opensolarisisdeadlongliveopensolaris) wrote:> Is that right? You can''t use zfs send | zfs receive to send from a newer version and receive on an older version? >No. You can, with recv, override any property in the sending stream that can be set from the command line (ie, a writable). Version is not one of those properties. It only gets changed, in an upward direction, when you do a zfs upgrade. ie: # zfs get version repo/support NAME PROPERTY VALUE SOURCE repo/support version 5 - # zfs send repo/support at cpu-0412 | zfs recv -o version=4 repo/test cannot receive: cannot override received version You can send a version 6 file system into a version 28 pool, but it will still be a version 6 file system. Bob
>On 12/14/12 10:07 AM, Edward Ned Harvey (opensolarisisdeadlongliveopensolaris) >wrote: >> Is that right? You can''t use zfs send | zfs receive to send from a newer version and receive on an older version? >>That is my experience. If you do a zfs upgrade on the sending machine, the receiving machine requires a version >= the sending machine.>No. You can, with recv, override any property in the sending stream that can be >set from the command line (ie, a writable). Version is not one of those >properties. It only gets changed, in an upward direction, when you do a zfs >upgrade.>ie:># zfs get version repo/support >NAME PROPERTY VALUE SOURCE >repo/support version 5 -># zfs send repo/support at cpu-0412 | zfs recv -o version=4 repo/test >cannot receive: cannot override received version>You can send a version 6 file system into a version 28 pool, but it will still >be a version 6 file system.>BobI am not disagreeing with this, but isn''t this the opposite test from what Ned asked? You can send from an old version (6) to a new version (28), but I don''t believe you can send the other way from the new version (28) to receive on the old version (6). Or am I reading this wrong? Chad
On Mon, Dec 17, 2012 at 9:36 AM, Truhn, Chad <Chad.Truhn at bowheadsupport.com>wrote:> > I am not disagreeing with this, but isn''t this the opposite test from what > Ned asked? You can send from an old version (6) to a new version (28), > but I don''t believe you can send the other way from the new version (28) to > receive on the old version (6). > > Or am I reading this wrong?ZFS version and zpool version are two separate version numbers: $ zfs get version mainpool NAME PROPERTY VALUE SOURCE mainpool version 5 - $ zpool get version mainpool NAME PROPERTY VALUE SOURCE mainpool version 28 local Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20121217/5d8bb105/attachment.html>