Before I put one in ... anyone else seen one? Seems we support compression on the root pool but there is no way to enable it at install time outside of a custom script you run before the installer. I''m thinking it should be a real install time option, have a jumpstart keyword, etc. Same with copies=2 Thanks.
How about a generic "zfs options" field in the JumpStart profile? (essentially an area where options can be specified that are all applied to the boot-pool (with provisions to deal with a broken-out-var)) That should future proof things to some extent allowing for compression=x, copies=x, blocksize=x, zfsPool-version=x, checksum=sha256, future-dedup, future-crypto, and other such goodies. (by just passing the keywords and having ZFS deal with it on the other end, the jumpstart code can remain quite static, while the zfs-side gradually introduces the new features. Just a thought, -- MikeE PS: At one point the old JumpStart code was encumbered, and the community wasn''t able to assist. I haven''t looked at the next-gen jumpstart framework that was delivered as part of the OpenSolaris SPARC preview. Can anyone provide any background/doc-link on that new JumpStart framework? -----Original Message----- From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss-bounces at opensolaris.org] On Behalf Of Torrey McMahon Sent: Tuesday, May 05, 2009 6:38 PM To: zfs-discuss at opensolaris.org Subject: [zfs-discuss] Compression/copies on root pool RFE Before I put one in ... anyone else seen one? Seems we support compression on the root pool but there is no way to enable it at install time outside of a custom script you run before the installer. I''m thinking it should be a real install time option, have a jumpstart keyword, etc. Same with copies=2 Thanks. _______________________________________________ zfs-discuss mailing list zfs-discuss at opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
On Tue, May 5, 2009 at 6:09 PM, Ellis, Mike <Mike.Ellis at fmr.com> wrote:> PS: At one point the old JumpStart code was encumbered, and the > community wasn''t able to assist. I haven''t looked at the next-gen > jumpstart framework that was delivered as part of the OpenSolaris SPARC > preview. Can anyone provide any background/doc-link on that new > JumpStart framework?I think you are looking for the Caiman project. The replacement for jumpstart is the Automated Installer (AI). http://src.opensolaris.org/source/xref/caiman/AI_source/usr/src/ http://www.opensolaris.org/os/project/caiman/auto_install/ This is mostly code developed in the open. I''m not aware of any closed pieces that are specific to the new installer. -- Mike Gerdts http://mgerdts.blogspot.com/
Casper.Dik at Sun.COM
2009-May-06 07:54 UTC
[zfs-discuss] Compression/copies on root pool RFE
>On Tue, May 5, 2009 at 6:09 PM, Ellis, Mike <Mike.Ellis at fmr.com> wrote: >> PS: At one point the old JumpStart code was encumbered, and the >> community wasn''t able to assist. I haven''t looked at the next-gen >> jumpstart framework that was delivered as part of the OpenSolaris SPARC >> preview. Can anyone provide any background/doc-link on that new >> JumpStart framework? > >I think you are looking for the Caiman project. The replacement for >jumpstart is the Automated Installer (AI). > >http://src.opensolaris.org/source/xref/caiman/AI_source/usr/src/ >http://www.opensolaris.org/os/project/caiman/auto_install/ > >This is mostly code developed in the open. I''m not aware of any >closed pieces that are specific to the new installer.I don''t remember a lot of "closed" parts in the old jumpstart. (lu is different) Casper
On Wed, May 6, 2009 at 2:54 AM, <Casper.Dik at sun.com> wrote:> >>On Tue, May 5, 2009 at 6:09 PM, Ellis, Mike <Mike.Ellis at fmr.com> wrote: >>> PS: At one point the old JumpStart code was encumbered, and the >>> community wasn''t able to assist. I haven''t looked at the next-gen >>> jumpstart framework that was delivered as part of the OpenSolaris SPARC >>> preview. Can anyone provide any background/doc-link on that new >>> JumpStart framework? >> >>I think you are looking for the Caiman project. ?The replacement for >>jumpstart is the Automated Installer (AI). >> >>http://src.opensolaris.org/source/xref/caiman/AI_source/usr/src/ >>http://www.opensolaris.org/os/project/caiman/auto_install/ >> >>This is mostly code developed in the open. ?I''m not aware of any >>closed pieces that are specific to the new installer. > > > I don''t remember a lot of "closed" parts in the old jumpstart. > (lu is different)Perhaps not closed for the same reasons, but I''ve not seen the open sourcing of anything related to installation other than pkgadd/pkgrm and associated libraries. Perhaps it would be possible to open source jumpstart but I suspect the motivation of anyone to spend the time to do so right now is almost none due to the focus on Caiman. This is probably better discussed at install-discuss, so I have redirected it there. -- Mike Gerdts http://mgerdts.blogspot.com/
Ellis, Mike wrote:> How about a generic "zfs options" field in the JumpStart profile? > (essentially an area where options can be specified that are all applied > to the boot-pool (with provisions to deal with a broken-out-var)) >We had this discussion a while back and, IIRC, it was expected that AI would offer this capability (I haven''t verified.) But as far as the interactive install, the goal was to ask fewer questions, not more. The existing and previous Solaris installers were considered far too complicated for people and the competition is fierce with all of the popular interactive installers much more simplified. I agree that interactive installation needs to remain as simple as possible. Note: in the Caiman world, this is only an issue for the first BE. Later BEs can easily have other policies. -- richard> That should future proof things to some extent allowing for > compression=x, copies=x, blocksize=x, zfsPool-version=x, > checksum=sha256, future-dedup, future-crypto, and other such goodies. > (by just passing the keywords and having ZFS deal with it on the other > end, the jumpstart code can remain quite static, while the zfs-side > gradually introduces the new features. > > Just a thought, > > -- MikeE > > PS: At one point the old JumpStart code was encumbered, and the > community wasn''t able to assist. I haven''t looked at the next-gen > jumpstart framework that was delivered as part of the OpenSolaris SPARC > preview. Can anyone provide any background/doc-link on that new > JumpStart framework? > > > > > -----Original Message----- > From: zfs-discuss-bounces at opensolaris.org > [mailto:zfs-discuss-bounces at opensolaris.org] On Behalf Of Torrey McMahon > Sent: Tuesday, May 05, 2009 6:38 PM > To: zfs-discuss at opensolaris.org > Subject: [zfs-discuss] Compression/copies on root pool RFE > > Before I put one in ... anyone else seen one? Seems we support > compression on the root pool but there is no way to enable it at install > > time outside of a custom script you run before the installer. I''m > thinking it should be a real install time option, have a jumpstart > keyword, etc. Same with copies=2 > > Thanks. > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >
On Wed, 6 May 2009, Richard Elling wrote:> popular interactive installers much more simplified. I agree that > interactive installation needs to remain as simple as possible.How about offering a choice an installation time: "Custom or default?"? Those that don''t want/need the interactive flexibility can pick default whereas others who want more flexibility (but still want or need an interactive installation) can pick the custom option. Just a thought... -- Rich Teer, SCSA, SCNA, SCSECA URLs: http://www.rite-group.com/rich http://www.linkedin.com/in/richteer
This sounds like a good idea to me, but it should be brought up on the caiman-discuss at opensolaris.org mailing list, since this is not just, or even primarily, a zfs issue. Lori Rich Teer wrote:>On Wed, 6 May 2009, Richard Elling wrote: > > > >>popular interactive installers much more simplified. I agree that >>interactive installation needs to remain as simple as possible. >> >> > >How about offering a choice an installation time: "Custom or default?"? > >Those that don''t want/need the interactive flexibility can pick default >whereas others who want more flexibility (but still want or need an >interactive installation) can pick the custom option. Just a thought... > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20090506/d148a64c/attachment.html>
On Wed, May 6, 2009 at 11:14 AM, Rich Teer <rich.teer at rite-group.com> wrote:> On Wed, 6 May 2009, Richard Elling wrote: > >> popular interactive installers much more simplified. ?I agree that >> interactive installation needs to remain as simple as possible. > > How about offering a choice an installation time: "Custom or default?"? > > Those that don''t want/need the interactive flexibility can pick default > whereas others who want more flexibility (but still want or need an > interactive installation) can pick the custom option. ?Just a thought...If you do propose this on caiman-discuss, I''d suggest an option to mirror 2 boot devices as well. Doing the slice attach/installgrub is nontrivial for, say, a user who''s primarily a dev.
>>>>> "re" == Richard Elling <richard.elling at gmail.com> writes:re> Note: in the Caiman world, this is only an issue for the first re> BE. Later BEs can easily have other policies. -- richard AIUI the later BE''s are clones of the first, and not all blocks will be rewritten, so it''s still an issue. no? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 304 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20090506/322b9941/attachment.bin>
Miles Nordin wrote:>>>>>> "re" == Richard Elling <richard.elling at gmail.com> writes: >>>>>> > > re> Note: in the Caiman world, this is only an issue for the first > re> BE. Later BEs can easily have other policies. -- richard > > AIUI the later BE''s are clones of the first, and not all blocks will > be rewritten, so it''s still an issue. no? >In practice, yes, they are clones. But whether it is an issue depends on what the "issue" is. As I see it, the issue is that someone wants to make install more complex, and thus lose the gains Caiman brought to the product. So, I''ll stand by my comment, you can change policies later. -- richard
Richard Elling wrote:> Miles Nordin wrote: >> AIUI the later BE''s are clones of the first, and not all blocks >> will be rewritten, so it''s still an issue. no? > > In practice, yes, they are clones. But whether it is an issue > depends on what the "issue" is. As I see it, the issue is that > someone wants to make install more complex, and thus lose the gains > Caiman brought to the product. So, I''ll stand by my comment, you can > change policies later. -- richardNo, the "issue" is wanting a compress root FS. So if you can''t set it for the first OS BE, and other BEs are clones, then it''s still an issue. Useful tools in the real world are complex. Sorry, but that''s reality. You can have a stupid and easy mode, you can even have it be the default, but if it''s the only mode you''ve made the product useless for serious work. -- Carson
Carson Gaspar wrote:> Richard Elling wrote: >> Miles Nordin wrote: >>> AIUI the later BE''s are clones of the first, and not all blocks >>> will be rewritten, so it''s still an issue. no? >> >> In practice, yes, they are clones. But whether it is an issue >> depends on what the "issue" is. As I see it, the issue is that >> someone wants to make install more complex, and thus lose the gains >> Caiman brought to the product. So, I''ll stand by my comment, you can >> change policies later. -- richard > > No, the "issue" is wanting a compress root FS. So if you can''t set it > for the first OS BE, and other BEs are clones, then it''s still an issue. > > Useful tools in the real world are complex. Sorry, but that''s reality. > You can have a stupid and easy mode, you can even have it be the > default, but if it''s the only mode you''ve made the product useless for > serious work.I''ll call bull* on that. Microsoft has an admirably simple installation and 88% of the market. Apple has another admirably simple installation and 10% of the market. Solaris has less than 1% of the market and has had a very complex installation process. You can''t win that battle by increasing complexity. It is relatively simple to make this happen without changing the interactive installer at all: http://blogs.sun.com/glagasse/entry/howto_enable_zfs_compression_when But for most sites who will be doing large scale installations at sites, they will not be using interactive installers. -- richard
Casper.Dik at Sun.COM
2009-May-07 15:26 UTC
[zfs-discuss] Compression/copies on root pool RFE
>I''ll call bull* on that. Microsoft has an admirably simple installation >and 88% of the market. Apple has another admirably simple installation >and 10% of the market. Solaris has less than 1% of the market and has >had a very complex installation process. You can''t win that battle by >increasing complexity.I''ve never installed Apple OS X but I have installed Microsoft; it''s NOT at all easy. Or perhaps you are referring to "no-one really installs Microsoft at all"? This is true; systems come with MS Windows installed and a CD (if provided) which will reinstalls ON YOUR HARDWARE (but not on other).>It is relatively simple to make this happen without changing the interactive >installer at all: >http://blogs.sun.com/glagasse/entry/howto_enable_zfs_compression_when > >But for most sites who will be doing large scale installations at sites, >they will not be using interactive installers.But you will need to provide an escape hatch. (And I''m fine for interactive install to allow you to start a shell window but AI install needs to provide an escape hatch) Casper