Sysinstall automatic filesystem size generation.

Oliver Fromme olli at lurza.secnetix.de
Tue Aug 30 10:48:08 GMT 2005


Chuck Swiger <cswiger at mac.com> wrote:
 > Jon Dama wrote:
 > > yes, that's quite generous.
 > > 
 > > why isn't /tmp just an mfs mount though?
 > 
 > While I like that suggestion personally, some people get perturbed about files 
 > in /tmp going away if the power fails or you reboot.

Then those people should use /var/tmp instead of /tmp.

Traditional UNIX behaviour is that contents of /var/tmp
must survive a reboot, while contents of /tmp are not
guaranteed to survive a reboot (and in fact, /tmp might
be cleaned completely at regular time intervals via a
periodic cron job or similar).  That's why vi puts its
recovery files under /var/tmp, not /tmp.

However, there are still cases where it's not desirable to
make /tmp a memory-based file system, e.g. on systems that
have little RAM and/or no swap (or NFS swap).  Also, some
people argue that a UFS disk partition with softupdates (or
even async) is fast enough for most purposes to be mounted
on /tmp.  (For what it's worth, I've seen systems set up in
a way to newfs the /tmp partiton on reboot.)

Therefore, I think the best solution would be to make it an
option in sysinstall:  If the user doesn't create a separate
partiton for /tmp in the partition editor, ask him whether
he would like to make /tmp a memory-based file system.  Or
implement a special hotkey in the partition editor for
creating a memory-based file system -- I guess this would
be the easiest way to implement it.

Best regards
   Oliver

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

"I invented Ctrl-Alt-Delete, but Bill Gates made it famous."
        -- David Bradley, original IBM PC design team


More information about the freebsd-stable mailing list