Re: [PLUG] Using 'noatime' in fstab?

[JP Vossen <jp@jpsdomain.org>]

 > Date: Wed, 19 Mar 2008 22:45:08 -0400
 > From: brent timothy saner <brent.saner@gmail.com>
 > Subject: Re: [PLUG] Using 'noatime' in fstab?
 >
 > JP Vossen wrote:
>> I read someplace that you can reduce wear and tear on hard drives
>> by including noatime in the mount options. I already do this for
>> the one system I have using a CF card, but I was wondering about it
>> just in  general.
 >>
>> I have several servers that rsync themselves various places for
>> backups. That means that every time I rsync the entire filesystem,
>> a gazillion atimes are being updated for essentially no reason.
>> Ditto for the s/locate indexer. I can't recall ever using an atime
>> for anything (ctime and mtime yes, atime no).
 >>
>> Can anyone give me a good reason not to do this on some/all of my 
>> machines? All of my machines are ext3, some have H/W EIDE RAID,
>> others have software (MDM) mirroring, some are just plain old hard
>> drives, if it matters. Most are Debian or Ubuntu but I have a
>> couple of CentOS4 boxes too. And what about for machines in a VM?
 >
 > it is in my general opinion that for most contexts, atime is
 > absolutely useless. i'd venture that it really doesn't offer much a
 > benefit (and yes, it DOES do more wear-and-tear).

It recently occurred to me tmpreaper does use atime, though it has 
options for using m or ctime as well.  The stock Debian Etch 
tmpreaper.conf uses atime AFAICT.  Since my /tmp is on a different 
partition, I've just left atime alone on that one.


 > two things, though.
 >
 > 1. please please PLEASE don't use ext3 with CF, use ext2 or fat (and
 > please don't use fat. it's useless). all that journaling can
 > potentially kill your storage if you're using CF.

Errr, that's a good point I'd not considered.  In my case it doesn't 
matter much, as the CF-card isn't written to very often.  All syslog 
goes elsewhere, and swap, /tmp and /data are on a hard disk.  Since it's 
a pain to get console access, I'm going to leave ext3 to less the 
chances of getting stuck at fsck after ungraceful shutdowns.  (It has a 
UPS, but...)

FAT?  Yuck.  I'd use ext2 if it mattered.  I use FAT32 on some USB 
drives that need to be portable, but otherwise... :-)


 > 2. another really smart idea is to mount /var/log, /var/tmp, and /tmp
 > (and more as you see fit) as ramdisks. you can do this by adding the
 > following to fstab:

I disagree there.  The FHS specifies that /var/tmp contents must be 
persistent across reboots [1].  And being a Security Geek I definitely 
don't agree with throwing logs away (I just send everything to a 
logserver).  /tmp would be OK though.

At any rate, in this particular case I'm much more RAM constrained than 
disk constrained.  / and the OS are on CF, but there is 500G hard disk 
for data and other, including /tmp.  I don't think I moved /var/tmp, but 
very little happens on the machine that needs that.  (Just checked, the 
only thing in /var/tmp is a vi.recover from 2005 and the only thing in 
/tmp is SSH sessions. :)


Of possible interest is that the CF card contains a fairly minimal 
Debian Etch (just upgraded from Sarge), plus OpenSSH, Postfix, Samba, 
NFS, Apache2, Bind9, gcc, NTP, SVN, DHCP3, and BackupPC in 469M.  81M of 
that is /usr/share which could go away, and there are other places I 
could trim, but it not worth the time since the CF is 1G.


Later,
JP
_______________
[1] http://www.pathname.com/fhs/pub/fhs-2.3.pdf, page 38:

5.15. /var/tmp : Temporary files preserved between system reboots
5.15.1. Purpose

The /var/tmp directory is made available for programs that require 
temporary files or directories that are preserved between system 
reboots. Therefore, data stored in /var/tmp is more persistent than data 
in /tmp.

Files and directories located in /var/tmp must not be deleted when the 
system is booted. Although data stored in /var/tmp is typically deleted 
in a site-specific manner, it is recommended that deletions occur at a 
less frequent interval than /tmp.
----------------------------|:::======|-------------------------------
JP Vossen, CISSP            |:::======|        jp{at}jpsdomain{dot}org
My Account, My Opinions     |=========|      http://www.jpsdomain.org/
----------------------------|=========|-------------------------------
"Microsoft Tax" = the additional hardware & yearly fees for the add-on
software required to protect Windows from its own poorly designed and
implemented self, while the overhead incidentally flattens Moore's Law.
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug