Date: Thu, 10 Oct 2013 07:04:10 +0000 From: "Teske, Devin" <Devin.Teske@fisglobal.com> To: Nathan Whitehorn <nwhitehorn@freebsd.org> Cc: "<freebsd-current@freebsd.org>" <freebsd-current@freebsd.org>, "Teske, Devin" <Devin.Teske@fisglobal.com> Subject: Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI Message-ID: <13CA24D6AB415D428143D44749F57D720FC4E9E0@LTCFISWMSGMB21.FNFIS.com> In-Reply-To: <5256509E.3000604@freebsd.org> References: <52531295.7090700@allanjude.com> <52546844.2010608@freebsd.org> <52549191.5010400@allanjude.com> <5254F582.1040406@freebsd.org> <13CA24D6AB415D428143D44749F57D720FC4B1F4@LTCFISWMSGMB21.FNFIS.com> <5256509E.3000604@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 10, 2013, at 12:00 AM, Nathan Whitehorn wrote: > On 10/09/13 18:55, Teske, Devin wrote: >> On Oct 8, 2013, at 11:19 PM, Nathan Whitehorn wrote: >>=20 >>> On 10/09/13 01:13, Allan Jude wrote: >>>> On 2013-10-08 16:17, Nathan Whitehorn wrote: >>>>> On 10/07/13 21:59, Allan Jude wrote: >>>>>> Devin Teske and I have been working on a big patch to bsdinstall to >>>>>> implement installing on a ZFS pool. It supports both GPT and MBR, th= e 4k >>>>>> sector gnop trick, and optional GELI encryption. We would like to co= mmit >>>>>> this in time for 10.0-BETA1 so it needs some testing to work out any >>>>>> obvious bugs before we send it off to re@ to get it committed. >>>>>>=20 >>>>>> It includes a single configuration menu that allows you to select al= l of >>>>>> the required details, including which drives to use (gets details fr= om >>>>>> camcontrol, also includes an inspection utility that presents the >>>>>> detailed output of camcontrol inquiry/identify, and gpart show), what >>>>>> ZFS RAID level to use (taking in to consideration the selected numbe= r of >>>>>> drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc. >>>>>>=20 >>>>>>=20 >>>>>> Additional, it includes some other changes to bsdinstall: >>>>>> 1. Change the default to the 'non-standard keyboard mapping' prompt = to no >>>>>> 2. Replace the 3 separate dialogs to configure an ipv4 address with = just 1 >>>>>> 3. Remove the dialog asking if you wish to enable crash dumps, this >>>>>> feature has been combined into the regular 'services to enable' dial= og >>>>>> and enabled by default >>>>>>=20 >>>>>>=20 >>>>>> You can browse the patches here: >>>>>> http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/ >>>>>>=20 >>>>>> I've built a bootonly.iso (10.0-ALPHA4) to make testing easier, >>>>>> available compressed (48 MB) or uncompressed (211 MB): >>>>>>=20 >>>>>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz >>>>>>=20 >>>>>> http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso >>>>>>=20 >>>>>>=20 >>>>>> We look forward to your feedback >>>>>>=20 >>>>> Thanks for doing this! I had a few comments: >>>>> 1. ZFS is not bootable on all architectures. Could you adjust that me= nu >>>>> item to only display for i386, amd64, and (I think?) sparc64. Use una= me >>>>> -m, not -p, for this. >>>> I had not considered that, I'll make that change >>>>=20 >>>>> 1a. The script is broken on sparc64 in any case, which uses VTOC8 >>>>> instead of GPT. >>>> I'll disable sparc64 as well >>>>=20 >>>>> 2. Why are you using camcontrol? That is guaranteed not to work on >>>>> non-CAM systems. You should use the GEOM ident string if you need an = ID. >>>> The GEOM ident string doesn't do enough to help the user identify which >>>> drive is which. >>>> More data is not exposed anywhere that I could find >>>>=20 >>>> What we really need, is dev.ada.0.desc% like we have for network >>>> interfaces and a slew of other devices. GEOM data is great, but it is >>>> not exposed in a shell friendly way any place that I could find, other >>>> than the sysctl with DOT and XML data. >>> This is one of the reasons the partition editor is written in C. There >>> are a few other odd corner-cases where C is much more powerful than the >>> command-line for the GEOM operations that partedit needs to do. I'm not >>> sure how to usefully get it just from the shell. You can see how to do >>> it in C in the boot_disk() routine of partedit/auto_part.c. >>>=20 >>>>> 3. Any plans to integrate this into the regular partition editor? ZFS >>>>> support is important enough that I will definitely not get in the way, >>>>> even as a bolt-on, but it would be a shame for it to stay that way. T= he >>>>> editor is also designed for ZFS to be added. >>>> I am a sysadmin, not a programmer. I can't write C. Most people >>>> deploying servers can't write C. I agree with Devin Teske, if everythi= ng >>>> was in shell it would be a lot more usable for non-developers, who >>>> probably make up the majority of people who deploy FreeBSD. >>> There are some cases the other way too. Devin is probably the most >>> shell-proficient FreeBSD committer. >> Well, there's jilles ;D (he writes/maintains the sh(1) implementation it= self). >>=20 >>=20 >>> I certainly can't write shell >>> scripts at that level, which means that for me bsdconfig, for example, >>> is effectively read-only (and quite hard to read as well). >> In the past few days of working on the bsdinstall_zfs patch-set with All= an >> Jude, I learned something new actually. >>=20 >> It seems that sh(1) doesn't suffer so much from this "read only" concept. >>=20 >> Imagine you're starting a new C project on an operating system that has >> all new syscalls and all new APIs that you've never seen. Would be pretty >> hard, no doubt. Now imagine that you're thrown a life-line called POSIX >> and hey, now you're slinging code in MinGW on Windows when you don't >> know a lick of M$ syscalls or APIs. >>=20 >> In a similar manner, I've witnessed functionality be added that is truly >> functional *without* using any of the API calls. Then I come in and do >> a round of optimizations to leverage the existing API. >>=20 >> Shell is kinda like that... >>=20 >> I'm noticing Allan Jude doesn't know all the API calls yet (who could? o= ther >> than me of course -- and even I have trouble remembering them _all_) yet >> this doesn't phase him (or others) from jumping in and lending a hand. >>=20 >> No different than C, but the read-only aspect is lessened significantly I >> believe because there are so many people out there that know enough >> good shell syntax and are just a stone's throw away from *great* shell >> syntax (which I must admit jilles helped me cross that boundary). >>=20 >> I think in C, the read-only aspect is greater because its harder to parc= el-out >> the functions for a unit-test; harder to inject new code; and harder to = get >> to a functioning end-state. >=20 > Look, I have no doubt that in the right hands shell can do amazing > things and C can be badly written. That isn't the issue though. My > statement was purely that most FreeBSD developers (me included) are more > comfortable with C than shell when used at the kind of level involved > here. This is not a value judgment but a statement of fact. Whether or > not, at some platonic level, shell or C or python or whatever are more > or less read-only is not the point here. The point is that I, and I > suspect many other developers, cannot write (or read) very advanced > levels of shell scripting but can read and write the equivalent programs > when written in C in many cases. It's what the rest of the system is > written in and what we spend most of our time using. Whether this should > be the case or not is immaterial; the fact remains that shell scripting > at any but a very basic level does introduce a very large barrier to > entry for probably a large majority of committers. >=20 > This is not always a problem -- especially if using something more > obscure allows very active development by the set of people working on > it -- but does reduce the set of people who can make modifications > substantially. I have no ability to change, or understand, most of > bsdconfig, for example. This isn't a problem since you are doing all the > work and there is no reason I would need to or want to make changes to > it. But it could become a problem in a part of the system to which > multiple people needed to contribute. It's about other people's comfort > zones and knowledge in the end. I can see that. And well said -- very well spoken. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?13CA24D6AB415D428143D44749F57D720FC4E9E0>