On 09/25/09 09:58 PM, David Magda wrote:
The contents of /var/tmp can be expected to survive between boots (e.g.,
/var/tmp/vi.recover); /tmp is nuked on power cycles (because it's just
memory/swap):
Yes, but does mapping it to /tmp have any issues regarding booting
or image-update in the context of this thread? IMO nuking is a good
thing - /tmp and /var/tmp get really cluttered up after a few months,
the downside of robust hardware and software :-). Not sure I really
care about recovering vi edits in the case of UPS failure...
If a program is creating and deleting large numbers of files, and those
files aren't needed between reboots, then it really should be using /tmp.
Quite. But some lazy programmer of 3rd party software decided to use
the default tmpnam() function and I don't have access to the code :-(.
tmpnam()
The tmpnam() function always generates a file name using the
path prefix defined as P_tmpdir in the <stdio.h> header. On
Solaris systems, the default value for P_tmpdir is
/var/tmp.
Similar definition for [/tmp] Linux FWIW:
Yes, but unless they fixed it recently (>=RHFC11), Linux doesn't actually
nuke /tmp, which seems to be mapped to disk. One side effect is that (like
MSWindows) AFAIK there isn't a native tmpfs, so programs that create and
destroy large numbers of files run orders of magnitude slower there than
on Solaris - assuming the application doesn't use /var/tmp for them :-).
Compilers and code generators are typical of applications that do this,
though they don't usually do synchronous i/o as said programmer appears
to have done.
I suppose /var/tmp on zfs would never actually write these files unless
they were written synchronously. In the context of this thread, for
those of us with space constrained boot disks/ssds, is it OK to map
/var/tmp to /tmp, and /var/crash, /var/dump, and swap to a separate
data pool in the context of being able to reboot and install new images?
I've been doing so for a long time now with no problems that I know of.
Just wondering what the gurus think...
Havn't seen any definitive response regrading /opt, which IMO should
be a good candidate since the installer makes it a separate fs anyway.
/usr/local can definitely be kept on a separate pool. I wouldn't move
/root. I keep a separate /export/home/root and have root cd to it via
a script in /root that also sets HOME, although I noticed on snv123
that logging on as root succeeded even though it couldn't find bash
(defaulted to using sh). This may be a snv123 bug, but it is a huge
improvement on past behavior. I daresay logging on as root might
also work if root's home directory was awol. Haven't tried it...
Cheers -- Frank
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
