We're also updating the EIS bootdisk standard, and are considering similar
recommendations.
File systems are still not free. They have costs in complexity and
maintenance, especially backup/restore. One of the benefits of a single
namespace is that it is relatively simple to backup and restore quickly.
However, I don't want to get sidetracked by the state of backup/restore
today. One benefit to multiple file systems is that you can apply
different policies, so if we stick to discussing policies (ok, including
backup/restore policies) then we should be able to arrive at a concensus
relatively easily :-)
Darren J Moffat wrote:
With reference to Lori's blog posting[1] I'd like to throw out a few of
my thoughts on spliting up the namespace.
This is quite timely because only yesterday when I was updating the ZFS
crypto document I was thinking about this. I knew I needed ephemeral
key support for ZVOLs so we could swap on an encrypted ZVOL. However I
chose not to make that option specific to ZVOLs but made it available to
all datasets. The rationale for this was having directories like
/var/tmp as separate encrypted datasets with an ephemeral key.
cool
So yes Lori I completely agree /var should be a separate data set, whats
more I think we can identify certain points of the /var namespace that
should almost always be a separate dataset.
Other than /var/tmp my short list for being separate ZFS datasets are:
/var/crash - because can be big and we might want quotas.
savecore already has a (sort of) quota implementation. I think the policy
driving this is backup/restore, not quota. I'd rather not spend a bunch of
time or tape backing up old cores.
/var/core [ which we don't yet have by default but I'm considering
submitting an ARC case for this. ] - as above.
ditto
/var/tm Similar to the /var/log rationale.
[assuming /var/tmp]
It is not clear to me how people use /var/tmp. In other words, I'm pretty
sure that most people don't know /var/tmp exists, and those that do know
use it differently than I do. Perhaps the policy driving this should be quota.
methinks we need a table...
As Robert points out, life becomes so much easier if split/merge existed :-)
-- richard
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
