As one of the people who suggested that I'd personally keep my root pool and data pool separate... here's my take:
ZFS provides the ability to have lots of datasets within a pool (which are the loose equivalent of mountpoints in the old world). The administrative cost of these is relatively low (apart from the increase in boot time as the number of datasets gets into the thousands), and it allows fine grained control of the characteristics of each of these datasets. In other words, ZFS in general will allow us to very easily create and manipulate multiple datasets within a pool. This is good, and is likely to make us trend towards having lots of datasets within pools. The implementation of ZFS boot requires the provision of a root pool, which has a couple of limitations: the primary one being that we only support mirrored underlying devices within that pool. See: http://www.opensolaris.org/os/community/arc/caselog/2006/370/onepager (4.1.2.1). This means that the root pool may not necessarily give me the storage characteristics I require for my data. The design of the root pool allows multiple BEs to be present in that pool, and allows all the groovy LU stuff which will soon become available. Given that we'll be snapshotting, there is no big drawback to having other things in the root pool. However, we are also moving towards a much more virtualised world, where we can/will have multiple zones, and these zones may even have the ability to run on multiple different server targets. From that point of view, it seems sensible to me that we should ensure that we can always disentangle the "data/application/non O/S specific content" from the O/S itself, hence the suggestion to have a separate root and data pool. For starters, it means that my data pool can be a RAIDZ config as opposed to being limited to mirrored. (In fact I'd suggest you might want to maintain several different pools depending on the performance and availability characteristics of the data.) You might also want to be able to export that pool to other machines. Hypothetically, if you decided that you only wanted a single root pool, (and there are a lot of reasons why you would: non-SAN/NAS attached server with a pair of internal disks), then I'd still ensure that my "data" was in separate datasets, as it is quite likely that I would want to for instance snapshot them differently from my root dataset. Mike UNIX admin wrote: >> With 320GB drive virtually being given away in >> cornflake packets these >> days, who cares? >> > > ... > > >> Again, what's a spare 16G slice on a modern drive, 5% >> or less. >> > > That's how "bloatware" came to be. It's also called "regression" in some > circles. > No space, no matter how big or small should be wasted because of a bad > concept, especially when it doesn't have to be wasted at all. > > >> Another advantage of a spare slice for /export/home >> is it can be used >> for ZFS until ZFS is supported by the installer. >> Very handy for laptops. >> > > This is true, but it also stands that this is temporary, and what I'm looking > for is a long-term solution. Temporary never was my style to begin with. > > >> Probably a waste of time as the move is towards ZFS >> boo and snap upgrades. >> > > In case you haven't noticed, some people on this list maintain that there > should be discrete pools for the OS and "data". My position on this is that > this would be a serious error which goes against the very idea of ZFS pooling > all the storage together for optimal space utilization. It is simply > inefficient and unnecessarily wasteful. > > > This message posted from opensolaris.org > _______________________________________________ > install-discuss mailing list > install-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/install-discuss > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: <http://mail.opensolaris.org/pipermail/install-discuss/attachments/20070821/7c3716df/attachment.bin>
