UNIX admin wrote:
> 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.
>
>
I can address this one. There ARE some good reasons to
have separate pools for the OS and for data:
- most importantly, at first release, zfs boot will not be supported
on striped or RAID-Z pools. Only mirroring will be supported.
This is a restriction one may not want to place on data.
- There is some advantage to separating the "personality" of a
system from its data. Data can be accessed from many machines.
There might be good reason to move data from one machine to
another. A system's root file systems, however, are pretty much
permanently associated with one machine. Also, you might want
to treat the contents differently. Suppose you want to do a zfs
upgrade of your pool in order to achieve some new feature,
but there are root file systems in your pool that are of an older
version that can't interpret the newer zfs on-disk format and for
whatever reason, you still want those older root file systems to
be bootable.
Whether these considerations apply to a given system is totally
dependent on how the system is going to be used and how many
disks it has. For systems with multiple disks (more than just two
for mirroring), it might be best to dedicate a couple disks to
a mirrored root pool and put the others in a separate pool where
the restrictions against RAID-Z and striping do not apply.
For systems with only a couple disks, mirroring them both into one
pool which is used for both root file systems and data may be best.
The installation procedure will allow either configuration.
Lori
