UNIX admin writes: > Removal of /export/home as a separate slice is very much needed, simply > because that particular layout uses disk space very inefficiently: for > example, under that particular layout, AND under "discrete filesystems" > layout in general, there will be filesystems which are barely used, while > other filesystems will be full.
That may well happen on some systems. > Determining the correct layout is empirically impossible and over the years > has resulted in arcane *gut feel* sizes of filesystems. True, but this will be mostly irrelevant when ZFS roots are delivered, because the units of currency will change dramatically. Instead of talking about discrete and hard-bounded file systems on disk slices, we'll be talking about a storage pool (or perhaps multiple pools in some installations) and the contents of them. It's a very different discussion. I agree that there are some common underlying concepts (how much should OS and data mingle?), but the configurations and issues are so different that it's pointless to discuss old-style slicing. > Simply put, the default disk layout as it is today does not use the available > disk space optimally nor efficiently. As others have pointed out, (1) disk space is pretty cheap and (2) slicing itself becomes much less interesting when storage is pooled. > > Given the difficulty in setting it up later > > (essentially "can't" for > > many systems), I think LU ought to come > > pre-configured out of the box. > > LU is wonderful and everything, but it has one major drawback, and that is > seriously wasting disk space. In order to use LU, one must allocate disk > slices which may or may not be used for an upgrade. Wasted space is traded off here with the ability to do in-place upgrades and patching without downtime. I agree that Flash Archives are quite helpful and useful, but they're certainly not right for _every_ deployment. Thus the problem: just like the existing defaults, what you're recommending works well for some but is abysmal for others. > LU is not relevant to this particular issue because the current default > layout doesn't accomodate for it anyways. It's relevant because you're proposing change in the way the installer slices up the disk by default. If we're going to propose change there, then the issue of what the _best_ default should be is certainly on the table. You seem to think that doesn't include LU, because you find it wasteful and don't want to use it. Does that speak for everyone? Is it really the best practice for a sufficient number of installations that precluding the use of LU by default is the right decision? That's the leap I can't make here. > Let us please leave LU out of this particular discussion and concentrate on > the default / inadequate disk layout. I disagree. LU is _definitely_ in that mix. > Back to my question: should I simply file an RFE? Go ahead, but expect it to be ignored. As long as we're in the process of reworking things to work with storage pools, the issue no longer really matters. UNIX admin writes: > > Yep; it's an argument about the Titanic deck chair > > arrangement. > > Excuse me, but the same argument can be carried over to the separate pools > for root FS and data scenario: most systems that will be running Solaris (as > it picks up volume) are single systems with internal storage, usually two > disks. What is the point of having separate pools if they reside on the same > physical devices? If one or more of those devices experiences catastrophic > failue, all pools, regardless of their separation, will be affected. Disk slices aren't really the right way to deal with those issues because ZFS works _much_ better when given the whole disk to manage. That's a key benefit of ZFS roots. > The whole point of a ZFS pool as Jeff Bonwick imagined it was to use ALL the > storage capacity in your system optmially, without having to resort to > discrete and often inaccurate sizing. Right. Thus my Titanic deck chair comment. Talking about slicing is old-think. > To advocate separate pools for "root" and "data", is to defeat and go against > the very idea that Jeff Bonwick was trying to solve and promote in the first > place. I never suggested such a thing. I'm not sure where you got that. What I pointed out was that the slicing (default or otherwise) done by the installer is antiquated. Changes to it just don't matter because the whole thing is going to go away. Thus, by proposing a change to the default slicing, you're just rearranging those deck chairs. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
