On Sun, 2010-03-21 at 10:01 -0700, Gregory K. Ruiz-Ade wrote: > On Mar 21, 2010, at 1:20 AM, Olivier Tharan wrote: > > On Sat, Mar 20, 2010 at 6:37 PM, Dan Parsons <[email protected]> > wrote: > >> One thing that immediately comes to mind is it will be fsck'd every > >> time it's not unmounted cleanly (as opposed to just having its > journal > >> replayed for ext3). > > It's just a single-char change in /etc/fstab to disable fsck. > I've not really found any huge performance hit for running ext3 > instead of ext2, so I just leave /tmp as ext3, and then make sure I do > a: > tune2fs -c 0 -i 0 /dev/<tmpdev> > Then it's really just trusting the journal to do the right thing if > it's unmounted dirty, and if it's bad enough to force an fsck, it's > bad enough to mkfs /tmp again. > I've toyed with the idea of modifying the init scripts to simply force > a mkfs for /tmp at boot, but haven't been bothered enough to go > through with it yet.
Speaking as a sys-admin addressing the three-pillars [1.) Performance, 2.) Security, and 3.) Maintainability] 1.) If you have an app that needs a filesystem scratch tab then creating a separate volume is a good idea, but consider: 1.1.) Mounting noatime may make more difference than anything else. 1.2.) Mounting data=writeback is advisable. 1.3.) If the volume does not need to be persistent then consider using tmpfs, and don't use a 'traditional' filesystem at all. And fstab entry like - none /srv/tmpfs tmpfs size=256M,mode=1777 0 0 - will give you a very fast, and brand new, scratch filesystem on /srv/tmpfs every time the system mounts. 2.) DO NOT USE /tmp. /tmp can very much be viewed as an artifact. If your application scribbles in /tmp then any other process on the system can access its scribbles. Each application than needs a scratch area should have a private scratch area in /srv, /var/spool, or /var/lib (depending on site policy). Creating that directory, or setting up a tmpfs mount, for the application should be a standard step in application deployment. 3.) DO NOT BASTARDIZE YOU SYSTEM STARTUP SCRIPTS. You will eventually get hit by a bus or get a different job. If you hack your system's standard scripts - like mounting /tmp without an fsck or recreating tmp at book - you will break something, or something will break eventually. And the guy who has to fix it will have to figure out whatever his misguided predecessor did to ruin the system. NEVER BASTARDIZE YOUR SYSTEMS STARTUP SCRIPTS. JUST DON'T. EVER. Fix the issue correctly: by provisioning an application specific scratch area and/or using tmpfs. -- Adam Tauno Williams <[email protected]> LPIC-1, Novell CLA <http://www.whitemiceconsulting.com> OpenGroupware, Cyrus IMAPd, Postfix, OpenLDAP, Samba _______________________________________________ Tech mailing list [email protected] http://lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
