On Oct 10, 2013, at 10:54 AM, Allan Jude wrote: > On 2013-10-10 13:21, Warren Block wrote: >> [off-list reply] >> >> I have not tested the new version yet. Is there any chance it >> supports setting up a gmirror? >> >> Something I've been meaning to discuss with Devin is the concept of >> presets. The user would be able to choose from a list of presets: >> >> Filesystem Layout >> ----------------- >> Merged / filesystem >> Split /, /var, /tmp, /usr filesystems >> >> then >> >> Filesystem Type >> --------------- >> UFS >> ZFS >> >> then >> >> Disk Layout >> ----------- >> Plain disk >> Mirror >> RAID >> >> Those choices might change depending on earlier ones, like if they had >> chosen ZFS earlier they would get a choice of Mirror, RAID-Z1, >> RAID-Z2, and so on. >> >> All this would build up a configuration, and at the end the user can >> edit it (filesystem sizes, for instance), then pick Go and walk away. > > All of the UFS stuff is in C, so is read-only for me. > > It is something I'd like to do, but it is really iffy if that can be > done in time for 10.0 > > In general, gmirror support could be added to the ZFS section (renamed > to something else). So in our current 'zfs' menu, would become the 'new > partition manager' menu. Add an extra option for ZFS or UFS, and then > the vdev menu would context switch between zfs vdevs and ufs options > like gmirror and gstripe or something > > Adding an extra option for / or / /var /tmp /usr is not a bad idea > either, maybe even for ZFS, offering a simpler set of datasets that > might be some people's preference (especially if I can't do the > following in time:) > > In a future revision of the zfsboot stuff, I'd like to offer a dialog > where users can actually adjust the ZFS datasets. provide a menu listing > the created dataset, with option to add more, and when you select a > dataset, you can adjust its options or delete it (some really scary > validation needs to happen here so you can't delete /usr if you have > /usr/local) > > If the UFS stuff took the form of the current ZFS stuff (give me the > entire disk, and i'll run with it), it would be fairly easy to > implement, and could probably be done between 10.0-BETA1 and 10.0-BETA2 > > The more powerful features of the current partedit code, where it > actually shows what is on your disk already, and allows you to just > adjust it, and in general manage dual booting etc, that is a lot more > complicated. > But the API exists (and we get a taste of the API in zfsboot). Specifically, a script would mangle a disk and then call f_device_rescan to get the menus to populate new entries. That aside, one of my plans for diskmgmt was to essentially let the user perform free-wheeling adhoc configurations. Here's an extreme example of what I mean**: 1. Boot a box with naked disks 2. Create some gmultipath labels 3. Put a GPT scheme on the disk with one BSD partition 4. Put some UFS labels in the partition 5. Build a zpool out of a secondary label of each multipath'd disk ** Because afterall, FreeBSD shouldn't prevent you from doing something like that. I think that if we try to tackle scenarios like that, then we'll really come up with a winning diskmgmt module (because right now I can't go do some UFS setup and then shove the products into a zpool). _When_ the ZFS management stuff is all integrated (which I plan on integrating bits from pjd's zfsconf too), I think it should be agnostic about what you give it as a device *and* allow you to configure many types of things without being forced into an "either-or" situation (because often it can be a "I want both" situation). (tuppence) -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.Received on Thu Oct 10 2013 - 16:07:07 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:42 UTC