On 12/01/14 16:38, Maxim Khitrov wrote: > On Tue, Nov 18, 2014 at 7:43 AM, Theo de Raadt <dera...@cvs.openbsd.org> > wrote: >>> /var/tmp has been changed to be a symlink to /tmp. Traditionally, >>> the difference between /tmp and /var/tmp has been that the former is >>> cleaned after a reboot, while the latter isn't. Making /var/tmp a >>> symlink to /tmp means it's no longer practical to make /tmp a ramdisk. >>> Is this a wise change? >> >> That distinction is a historical mistake. Read the commit message. > > I also have /tmp as a tmpfs mount and my concern, in addition to > vi.recover, is that the upgrade guide for 5.6 explicitly mentions > backups of files replaced by sysmerge surviving a reboot in /var/tmp > (at least for a few days). What will happen in 5.7?
IF your /tmp is a non-persistant file system, yes, you will lose your sysmerge results on next reboot (which doesn't happen automatically -- you can save your data if you wish to) UNLESS you read the man page and set the appropriate environment variable before running sysmerge. :) > The commit message says that some daemons assume they will not run out > of space in /var. Which ones? That seems like a really bad assumption. logs, mail, logs, web server uploads, logs, DNS zone transfers, logs I'm not so sure they simply assume they have unlimited space, but that it is a situation best avoided. Say you use the traditional DNS zone transfer process (I'm not advocating that!), you make your change on your master, it pushes out ... and one of the slaves is unable to write to /var to store it. Now what? Just not really a situation you want to "recover" from, much better to never have had it happen. Nick.
