On 4/24/07, Darren J Moffat <[EMAIL PROTECTED]> wrote:
Other than /var/tmp my short list for being separate ZFS datasets are:/var/crash - because can be big and we might want quotas. /var/core [ which we don't yet have by default but I'm considering submitting an ARC case for this. ] - as above. /var/tm Similar to the /var/log rationale.
How does this[1] play with live upgrade or a like technology? Presumably a boot environment is created with "zfs snapshot -r". There is very significant value in having the notion of "boot environment data" and app or user data on a server. By having this distinction, it greatly takes away the significance of the question that I keep getting from Sun folks: "how long are you OK between lucreate and luactivate?" One word of caution with "/var/core" is that it makes per-process core dumps for a process with cwd of /var impossible, assuming per-process core pattern is still "core". My approach to this is to have a global core dump pattern of /var/cores/core-%... and have core dump logging enabled. If /var/cores doesn't exist, I get a syslog message saying that the core dump failed which is usually all the information I need (no, the sysadmin didn't kill your process, your vendor's programmers did). In the relatively rare cases where I need to capture a core, I can create /var/cores then rename it once I have good data. [1] And additional proliferation of file systems proposed in this thread. Many file systems can be good but too many become a headache.
I think we have lots of options but it might be nice to come up with a short list of special/important directories that would should always recommend be separate datasets - lets not hardcode that into the installer though (heck we still think /usr/openwin is special !)
Most certainly. While I find separating file systems based upon software management boundaries[2], others feel there is more benefit in different strategies[3]. The installer needs reasonable defaults but should only enforce the creation of the set that is really the minimum. [2] /, /usr, /var, and /opt all belong together because everything there is managed by pkgadd/pkgrm/patchadd/patchrm. Some random app that installs in /opt/random-app through a custom installer (and as such is likely administered by non-root, is portable across boot environments) gets its own file system. /var/tmp has no software in it and can be abused to hurt the rest of the system - that's a good candidate for another FS. [3] Or are simply afraid to deviate from the advice they received in 1988 to have / and /usr as separate file systems
One of the things I'm really interested in seeing is more appropriate sharing with Zones because we have more flexibility in the installer as it becomes zone aware. What I'd love to see is that we completely abandon the package based boundaries for Zones and instead use one based only on the actual filesystem namespace and use Zones to get the best out of that.
I don't follow this. It seems to me that zones are very much based upon file system name space and not on package boundaries. For example, a package that has components in /etc and /usr (for better or for worse) installs, uninstalls, and propagates into full and sparse zones properly. I was actually quite impressed that this worked out so well. What I would find really useful is something that allows me to create a zone by cloning the global zone's file systems then customizing as required. When I patch the server (global zone, propagate patches to local zone), the global zone and the non-global zones should still be referencing the same disk blocks for almost everything in /usr, /lib, etc. (not /etc :) ). The best hope of this right now is some sort of de-duplication that seems not to be high on the list of coming features. This would give the benefits of sparse zones (more efficient use of memory, etc.) without the drawback of not being able to even create mount points for other file systems. Mike -- Mike Gerdts http://mgerdts.blogspot.com/ _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
