Automated partitioning of systems is always a difficult problem We (Rocks -- www.rocksclusters.org) have tried many approaches and have yet to find El Dorado. 90+% are served well with single disk, automatic layouts. The other ~10% are, well, challenging.
What we have now (Rocks version 5.0). Is what we call programmatic partitioning. there are other common cases that don't require programming. Please don't take my comments as "We (Rocks) know what we are doing ". Please take them as "this is what we do. it isn't perfect, but might be helpful" For the power user: We give a the user (in this case, the person designing _their version_ of automated partitioning) the ability to get a list of disks. see of http://www.rocksclusters.org/roll-documentation/base/5.0/customization-partitioning.html For a complete list of what we do now. One important aspect is 3.5.2.3 which is called programmatic partitioning -- gives a user the gun and the bullets. You have to look at the python code -- part of the (Rocks/Kickstart) environment includes calls to: p = rocks_partition.RocksPartition() disks = p.getDisks() What we do not have rigorously defined is the information that the installer gives you in the getDisks method (so our approach is more like tin instead of gold). Right now, it gives you a list of device names (but there probably should be other information so that one can differentiate between locally attached and san-attached disks) We have examples of creating raids, forcing a default partitioning, and completely punting and forcing people to do manual partitioning. You can sum up comments as that auto-installer should have an "escape hatch" that allows power programmers to write their own partitioning code without requiring them to attempt to probe the physical system for what's there. The other hard part is handling the case of installation vs. re-installation. At first time install, you need to create file systems when they don't exist. At reinstallation, you only want to reattach some file systems and reformat others. Regards, Phil On Thu, Jun 19, 2008 at 2:19 PM, Peter Tribble <peter.tribble at gmail.com> wrote: > On Fri, Jun 13, 2008 at 6:30 PM, Kyle McDonald <KMcDonald at egenera.com> > wrote: > >> Agree.. I didn't explicitly call this out, but we do intend to allow > >> users to specify which disk to to the install on. > >> > >> > > This is one area I'd like to see some innovation in. I agree with Mike > > that I'd like to be able to tell AI to ignore my SAN disks, but at the > > same time I'd like to not have to tweak the profile for each machine > > tiype where the local disk might be c1t0, vs c0t0, etc. > > This is a significant pain point in the current system. > > I don't know a good way of expressing this. But, for example, I need > to > > mirror c3t0ds0 and c3t1d0s0 to form / > mirror c3t2d0s0 and c3t3d0s0 to form /alt > swap onto c3t0d0s1, c3t1d0s1, c3t2d0s1, c3t3d0s1 > zpool create foo mirror c3t0d0s7 c3t1d0s7 mirror c3t2d0s7 c3t3d0s7 > > and the problem is that c3 may be c1, c2, c3, c4, whatever. > > So what I want to generically do is call disks > > cXt0d0s0 and cXt1d0s0 > > and have it ensure that it chooses two disks for which X is the same. > > The existing rules syntax allows you to choose things like 'disksize' and > 'totaldisk'. Not that I've ever used that particular feature. But we do > need a > richer way of specifying the target device(s). I can imagine 'disktype' > (sata, > sas, scsi, fibre) might be useful in some cases, but it needs to be pretty > flexible. > > An ignore option to simply skip any disks matching certain criteria might > make sense too. (Ignore 'Vendor=EMC' would eliminate the possibility of > accidentally overwriting the database on my SAN...) > > -- > -Peter Tribble > http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss > -- Philip Papadopoulos, PhD University of California, San Diego 858-822-3628 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/caiman-discuss/attachments/20080620/3835c58f/attachment.html>
