atom feed15 messages in org.opensolaris.caiman-discuss[caiman-discuss] ZFS data set division
FromSent OnAttachments
Dave MinerAug 22, 2007 2:45 pm 
Davi...@Sun.COMAug 23, 2007 11:46 am 
Mike GerdtsAug 23, 2007 3:12 pm 
Peter TribbleAug 23, 2007 3:16 pm 
Bart SmaaldersAug 23, 2007 3:20 pm 
Dave MinerAug 24, 2007 7:20 am 
Dave MinerAug 24, 2007 7:49 am 
Dave MinerAug 24, 2007 8:38 am 
Mike GerdtsAug 24, 2007 9:16 am 
Lori AltAug 24, 2007 9:54 am 
Peter TribbleAug 28, 2007 2:35 pm 
Richard L. HamiltonAug 29, 2007 2:30 am 
Mike GerdtsAug 29, 2007 7:36 am 
Richard EllingSep 2, 2007 5:55 pm 
Mike GerdtsSep 2, 2007 8:12 pm 
Subject:[caiman-discuss] ZFS data set division
From:Mike Gerdts (
Date:Aug 29, 2007 7:36:41 am

On 8/29/07, Richard L. Hamilton <rlhamil at> wrote:

If df by default suppressed pseudo-filesystems (either by having them all support the "ignore" option, or by defaulting to not showing filesystems with zero total space), that would cut out


Even the installed OS can reasonably be subdivided various ways, such as parts that are volatile and parts that should only change due to patches or upgrades (which interacts with LU, zfs cloning, etc). The volatile parts can sometimes be grouped into configuration-mostly and data-mostly, and data-mostly in turn may have system generated data vs application or email related data (/var/adm and /var/audit vs parts of /var/spool, /var/mail, /var/tmp, and so on).

With the current layout of /var, if one were to look at which directories could be shared directories (in this context, on shared file systems) you would end up with a rather long list of individual file systems to share:

adm idmap mail postgres spool audit inet news preserve statmon crash krb5 nfs saf webconsole cron ld ntp samba yp db ldap opt scn fm log passwd sma_snmp

This list (from snv_69) is based upon determining which directories contain no files delivered by a package and are not tmpfs file systems.

$ cd /var $ nawk '$2 == "f" { print $1 }' /var/sadm/install/contents \ | nawk -F/ 'NF > 3 && $2 == "var" { print $3 }' \ | uniq > /tmp/notshared $ for dir in * ; do grep "^$dir$" /tmp/notshared >/dev/null || echo $dir done

Upon further examination, one would likely find other directories like /var/svc/log that could be shared and may call into question why non-variable files (e.g. /var/svc/manifest/*/*.xml) exist under /var. /var/opt should probably be removed from the list because it would likely break third-party software.

I would really hate to see the typical boot environment have 30ish file systems. I would really like to see my proposal[1] for a reorg of /var such that /var/share is shared between boot environments to get some discussion.


That thinking pertains more to slicing than to zfs filesystems, but the notion of multiple templates might extend to that.

Aside from root and data pools, I'm not sure that I've seen a lot of reason to do a lot of slicing. I suspect that if a person has 4 300 GB drives in their machine and the OS takes two of them as the root pool, and gives the others as the data pool, the typical user is going to be quite unhappy. The enterprise user that connects a few terabytes of SAN may have a different view.

A desktop (even more so a laptop) could probably do fine with relatively few of even lightweight zfs filesystems (give or take a developer's desktop/laptop, which might allow for multiple BEs for testing, backporting, etc). But many servers might do well with something more sophisticated, with more than one variant reasonably obvious.

My experience is that a server may be more sophisticated only in that it is likely to have one or more file systems (old days, maybe pool(s) new days) dedicated to application use. A system with non-global zones is likely to have a file system per zonepath. Most server environments that I have seen lately are gravitating toward putting the entire OS in / or possibly / + /var. Pretty simple, really.

But then again, most servers I see are installed via jumpstart, not via the pretty installer we are talking about here. If the pretty installer is intended to be the tool to configure jumpstart profiles, an expert mode is essential.