Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Operating Systems Software Linux

Replacing Atime With Relatime in the Kernel 416

eldavojohn writes "Our friend Jeremy at the Kernal Trap has dug up some interesting criticism of atime from Linus Torvalds. As Linus submitted patches to improve relatime he noted: 'I cannot over-emphasize how much of a deal it is in practice. Atime updates are by far the biggest IO performance deficiency that Linux has today. Getting rid of atime updates would give us more everyday Linux performance than all the pagecache speedups of the past 10 years, _combined_.' And later severely beat atime about the head with a pointed stick: 'It's also perhaps the most stupid Unix design idea of all times. Unix is really nice and well done, but think about this a bit: 'For every file that is read from the disk, lets do a ... write to the disk! And, for every file that is already cached and which we read from the cache ... do a write to the disk!'" Well, I guess I can expect my Linux machine to become a little bit faster!"
This discussion has been archived. No new comments can be posted.

Replacing Atime With Relatime in the Kernel

Comments Filter:
  • Personally (Score:5, Interesting)

    by Nikron ( 888774 ) on Wednesday August 08, 2007 @05:11PM (#20162455)
    After I mounted my system with nodiratime and noatime, I did not 'feel' any actual speed increase. I didn't did any hard testing of course.
    • Re:Personally (Score:5, Informative)

      by ciroknight ( 601098 ) on Wednesday August 08, 2007 @06:30PM (#20163281)
      I can't "feel" a difference on my desktop with 2GB of RAM, but on my laptop which only has 1, and a much slower disk, the improvement is pretty noticeable (as in from "nearly unusable for lots of access applications [trackerd]" to "smooth as silk").

      It's funny the kernel devs are just now talking about this, I discovered this almost 6 months ago on the Ubuntu forums while glancing around for a fix for my laptop's ridiculous sound issues.
      • Re:Personally (Score:5, Informative)

        by Burz ( 138833 ) on Wednesday August 08, 2007 @08:12PM (#20164195) Homepage Journal
        I discovered noatime about 5 years ago, right about the same time I learned that DMA was turned off by default. I was horrified to hear that Linus' opinion of DMA at the time was 'no performance gain'.

        I'm surprised Linus is just cluing in now about atime updates: The noatime workaround is listed in all kinds of performance-tuning guides.
      • Re:Personally (Score:5, Informative)

        by Trepalium ( 109107 ) on Wednesday August 08, 2007 @09:06PM (#20164631)
        For a laptop, there is a more important reason to use noatime. Without that option the hard drives may never get the chance to spin down and save power because /bin/sync always has something to write to the disk (it's own atime update).
      • by Kadin2048 ( 468275 ) * <{ten.yxox} {ta} {nidak.todhsals}> on Thursday August 09, 2007 @01:58AM (#20166307) Homepage Journal
        Is this something that's limited just to Linux and the ext3 filesystem?

        I'm particularly curious as to whether it's an issue on Mac OS X with the HFS filesystem also, and whether it would be possible / advisable to force Mac OS X to mount the root HFS partition as noatime/nodiratime.

        OS X doesn't use a traditional UNIX-style fstab, so it's not immediately clear to me how you'd change the mount options (last time I checked disk mounting was all just in /etc/rc, but perhaps it's been moved into that new SystemStarter business since I last checked). It seems like the same things ought to apply to HFS -- it has an attribute that's functionally identical (at least, I think it is -- feel free to correct me on this) to atime, stored in the catalog file -- but I'm not familiar enough with the workings of the filesystems to know if that's actually the case.

        If this doesn't occur in other OSes (I picked OS X because it's the other OS that I use frequently, and it uses a default fileystem that's pretty different in design from ext2/3), it seems like it might be worthwhile to look at why that is, and what tradeoffs other OSes have made to avoid the same issue.
    • Re: (Score:3, Interesting)

      by Anonymous Coward
      What's more is that any performance sensitive partition is already mounted with noatime and nodiratime flags. It's only ever going to be a performance issue for those that neglect to turn it off.

      atime is useful for deleting files from working directories, I use it on my laptop graphic design partition. Anything untouched for 2 months is deleted by a shell script to free up space. The backups and archives are also mounted with atime, its usefulness to me in this role far outweighs the performance penalty.
    • by EmbeddedJanitor ( 597831 ) on Wednesday August 08, 2007 @06:35PM (#20163339)
      atime really hurts some file systems, particularly flash file systems. Many/most flash file systems don't support atime for that reason. So, even if you're running atime in the kernel you will often not be getting atime in the fs.

      If you're using a desktop system with a hard disk you'll hardly notice any difference unless you hammer the system really hard.

      Remember though that most Linux systems are either embedded (using mainly flash) or servers. In both these cases atime updates can be very damaging to performance and should be avoided unless there's a very good reason to turn it on.

    • Re: (Score:3, Informative)

      I just enabled it on my little file server at home.

      Specs:
      AMD 3000+, 512MB ram, 1x 80GB IDE, 2x 500GB SATA (Raid)

      MASSIVE difference in performance, even just doing an ls on a directory with a lot of files/directories in it.

    • Re:Personally (Score:4, Informative)

      by Suicyco ( 88284 ) on Wednesday August 08, 2007 @10:30PM (#20165131) Homepage
      Try it on a multi terabyte high speed raid0 for scratch data on a big box like a 64 cpu altix. noatime can give massive, and by massive I mean MASSIVE speed increases. atime is retarded, I totally agree with Linus.
    • Re: (Score:3, Interesting)

      by WNight ( 23683 ) *
      I checked what was mounted and found an extrernal 500GB via USB without noatime so I decided to try a test.

      I ran a 'find . > /dev/null' on the external drive. There were 250k files totallying roughly 450GB on ReiserFS.

      The first run took 50s, then it quickly stabilized between 1.5s and 6.5s, mostly around 4s. The cache obviously made a huge difference.

      Then I remounted with noatime and reran the test. It was very consistently at just under 0.7s.

      So, between 1.08 times faster and 6.4 times depending on if th
  • Ummm.. (Score:2, Funny)

    by Anonymous Coward
    Since I have no idea what atime or relatime actually are, could someone just tell me which kernel settings should be changed re: this story for an ideal desktop system?

    Thanks.
    • Re: (Score:3, Informative)

      by AKAImBatman ( 238306 )
      This is talking about the Last Access Time feature of most Unix systems. The OS will write a timestamp to disk each time the file is opened, closed, changed, or just looked at funny. Most professional Unixes (Solaris springs to mind) have the option of disabling the access timestamps. I haven't read the article yet, so I'm not quite sure why Linux hasn't followed suit by now. It's a security feature that's not all that useful on most systems.
      • Re:Ummm.. (Score:5, Informative)

        by Compholio ( 770966 ) on Wednesday August 08, 2007 @05:26PM (#20162655)

        Most professional Unixes (Solaris springs to mind) have the option of disabling the access timestamps. I haven't read the article yet, so I'm not quite sure why Linux hasn't followed suit by now.
        Linux has had the capability to turn off access timestamps for a long time. "man mount" has details, but all you really have to do is edit /etc/fstab:
        /dev/hda3 / ext3 defaults 0 1
        becomes
        /dev/hda3 / ext3 defaults,noatime,nodiratime 0 1
        • Re:Ummm.. (Score:4, Interesting)

          by AKAImBatman ( 238306 ) <akaimbatman AT gmail DOT com> on Wednesday August 08, 2007 @05:34PM (#20162741) Homepage Journal
          Yeah, I finally read the article. I thought I remembered that Linux could turn off atime, but I wasn't going to commit to it until I was sure.

          FWIW, the Relative Access Time (relatime) patch simply doesn't update the access time unless the file has been modified since the last atime write. That allows ancient applications like MUTT to still synchronize on various files. Synchronization that does not work with noatime set.

          Of course, I have to question why they're still using something as ancient as MUTT. A nice event system would be 1000x more efficient than trying to synchronize on flat files stored in your home directory on the file system. Of course, that would require designing OSes beyond the standard UNIX/POSIX philosophy and design. So I doubt we'll see that in Linux any time soon.
          • Re:Ummm.. (Score:5, Insightful)

            by vidarh ( 309115 ) <vidar@hokstad.com> on Wednesday August 08, 2007 @06:27PM (#20163255) Homepage Journal
            People are using Mutt because it works and has the features lots of people needs. I have to question why people keep upgrading just for the sake of it. As for an event system, Linux has had that too for ages - search for dnotify and inotify.

            However Mutt's use of atime simply is cheap enough that there's simply never been a reason to change it all the time most people have had atime updates on anyway. If it ain't broke, don't fix it.

          • Re:Ummm.. (Score:5, Interesting)

            by Cheesey ( 70139 ) on Wednesday August 08, 2007 @07:24PM (#20163777)
            Of course, I have to question why they're still using something as ancient as MUTT.

            The thing I really *really* like about Mutt is that it uses Unix mailbox files. These are not just human-readable, they can also be manipulated using tools like 'cat'. I periodically archive my working mail files into a backup directory by just concatenating the working files onto the archive files of the same name. The resulting archive mail files are still fully usable with Mutt, even though some are 100Mb+ in size with mail going back to 1997. I could also use them with even older mail clients such as Pine, but that would be like using vi when you've got vim.

            When I initially began using Linux, I used the Netscape email software, got fed up with it, and tried a few other mail clients. But none of them came close to the flexibility of Mutt. They all used their own mailbox formats, which could not be archived in the way I just described. I suspect that this is still true. I'm not going to trust Opera, Sylpheed, Thunderbird or Evolution with my mail, because (a) I doubt present-day mail files will still work reliably in 10 years time, (b) I can't easily migrate to another mail reader, and (c) I can't efficiently archive my email because the database files are not plain text.

            That's why I like Mutt, anyway.
            • Re:Ummm.. (Score:4, Informative)

              by hab136 ( 30884 ) on Wednesday August 08, 2007 @10:39PM (#20165197) Journal
              The old Netscape 4.x software also used Unix mailbox (mbox) files; it just also had index files. I'm not sure about current versions. mbox plus index was/is a popular storage format - mbox because it was simple, with added indexes for speed.

              Maildir [wikipedia.org] is my preferred format - each message is a separate plain text file, which means no locking issues, and simultaneous access from multiple machines. You can just tar the directory up if you want to move it, or cat all the files together if you want mbox back. You can use maildir with mutt [elho.net] (and lots of other software).
          • Re:Ummm.. (Score:4, Interesting)

            by Fweeky ( 41046 ) on Wednesday August 08, 2007 @07:46PM (#20163981) Homepage

            That allows ancient applications like MUTT to still synchronize on various files
            Mutt uses atime to cheaply determine if there are new files in a mbox, without needing to keep external metadata or scan for flags; if atime < mtime, put a 'N' in the index. Given atime's required by POSIX, and it's a non-critical feature I don't really see why this is a problem; it's not like it's the end of the world if it doesn't work. Maybe mutt could be explicit about wanting atime updated using utime(), or you could add a folder-hook to touch -a a mbox on open, assuming that still works on noatime mounts.

            It's also commonly used by cleanup scripts to delete rarely accessed temp files and such. I'm sure there are plenty of scripts in production dotted around doing things like find -atime +7 -delete, some probably quite recent.

            Of course, I have to question why they're still using something as ancient as MUTT
            Err, because it's a nice mail client? Do you also want to question why we're still using bourne compatible shells, vi derivatives, or Perl? Also, it's spelled "mutt" or "Mutt", not "MUTT". Anyone would think you were trolling...
          • In the email discussion linked in the article kernel devs were wondering the same thing... why doesn't mutt/bash just use inotify on the mailbox/maildir if available at config/build time? (Linux does have a event system in epoll and inotify -- and we almost got that unified under kevent, and it's threatening to happen again pulling in AIO too)

            They were also concerned about breakage of other systems that are not open source (HSMs) which use atime for usage tracking. Noting that HSMs and atime-sensitive maint
        • by ashayh ( 636057 )
          I believe noatime includes nodiratime.
        • Re: (Score:3, Informative)

          by Anonymous Coward
          "/dev/hda3 / ext3 defaults,noatime,nodiratime 0 1"
          Actually, noatime is a superset of nodiratime, so there is no need to specify both.
    • Re: (Score:3, Informative)

      by mpeg4codec ( 581587 )
      In your /etc/fstab, append noatime to the options of your main file systems. This will prevent the access timestamps of files and directories from being updated on each access. Not so sure what the relatime stuff is, but I imagine the use of noatime will also prevent the bottlenecks seen from relatime.
    • Re:Ummm.. (Score:5, Informative)

      by ArcherB ( 796902 ) * on Wednesday August 08, 2007 @05:22PM (#20162615) Journal
      In your /etc/fstab, add noatime to your options portion of you drive line. For example:

      /media/sda1 ext3 defaults,noatime 1 1
      atime logs when a file has been written or read. So every time a file is used, it has to write an entry on the HDD, slowing performance, but it can have uses, like in forensics, security or backups (if a file has not been read in three years, it's probably safe to archive and move off the drive). I don't care for it, so I have the noatime line in my fstab.

      • So every time a file is used, it has to write an entry on the HDD, slowing performance,... so I have the noatime line in my fstab.

        I have noatime set on my laptop.

        Writing atime to the disk every time data is read from the cache keeps the disk spinning, burning battery power. "noatime" means the disk can shut down much of the time, spinning up only when writes must be synced or data not yet in cache must be read.
        • by GoRK ( 10018 ) on Wednesday August 08, 2007 @06:18PM (#20163167) Homepage Journal
          Just a handy tip for you (if you don't already use it) or others who are looking at disabling atime more for the power savings than the IO -- on laptops you should also be using noflushd (non-journaling filesystems only) or (ideally) Laptop Mode Tools [catsifier.com]. Also do not forget to configure syslog so that it doesn't constantly sync writes.

          It's also worth mentioning that you *can* have atime enabled with properly configured laptop-mode and laptop-mode-tools and still see almost as much power savings -- The atime writes will still happen, but at least they will be buffered for when the HDD actually needs to spin up and do a lot of other more pressing IO.
      • Re:Ummm.. (Score:4, Interesting)

        by myowntrueself ( 607117 ) on Wednesday August 08, 2007 @07:50PM (#20164009)
        or backups (if a file has not been read in three years, it's probably safe to archive and move off the drive)

        Ummmm... if you are doing regular backups then the atime will be changing every time so you can't tell if the file has not *really* been read in three years.

        So atime is only useful in the case that you havn't backed that file up in three years and it has never even been accessed in that time... at which point I have to ask why you are only now deciding to archive it to offline media, if its relevence is really that low?

      • Re:Ummm.. (Score:5, Funny)

        by PopeRatzo ( 965947 ) * on Wednesday August 08, 2007 @08:24PM (#20164315) Journal

        I have the noatime line in my fstab.
        Ah, these are the kind of stories I first starting coming to Slashdot for.

        I don't think you can fully realize how poetic a phrase such as the one above can be until you read it with absolutely no understanding, as I do.

        Thank you, ArcherB and thank you, Slashdot.
    • They are talking about keeping track of (read) access times for files on your disk. I am not sure why Linus makes such a big deal about this since writing out the access times is deferred until some other write, anyways.

      You don't really need to change any kernel settings, just set the noatime flag for your disk if you don't need the functionality.
      • Re:Ummm.. (Score:5, Insightful)

        by mikeee ( 137160 ) on Wednesday August 08, 2007 @05:27PM (#20162675)
        Deferred, maybe, but not for more than a few seconds, and when it happens it means more disk seeks...

        It's long been standard practice to disable this on, eg, news/mail spools (anything with large numbers of read-mostly small files). The new plan of, if I understand correctly, only updating atime when the file is modified or if the new atime is more than 24 hours after the current atime should provide nearly the same functionality with practically none of the performance hit.
        • by Kjella ( 173770 )
          If you don't need accurate atime, then you don't need atime... then you need some sort of "access-o-meter" saying how often this file is in use. That file I've accessed once in the last year shouldn't be updated for fast access even if atime is five minutes ago, so what's it for? Nothing good that I can tell.
          • Re: (Score:3, Interesting)

            by mce ( 509 )

            It's good for finding files that are not being accessed anymore (doh). This may not be a big issue on a personal desktop, but in a corporate network with tons of centrally installed tools - and even more versions thereof - it very much is. I've made in the past extensive use of it for exactly that purpose.

            It's also good for automatically getting rid of the many defunct temporary files people tend to leave behind in shared directories such as /tmp. Again think multi-user machines.

            I've also used it as

  • Probably overblown (Score:5, Insightful)

    by jimicus ( 737525 ) on Wednesday August 08, 2007 @05:13PM (#20162481)
    Seriously. Many have recommended mounting filesystems with the "noatime" parameter if you don't need to know atime for many years now,
    • Re: (Score:3, Insightful)

      by Vellmont ( 569020 )

      Seriously. Many have recommended mounting filesystems with the "noatime" parameter if you don't need to know atime for many years now,

      Except for the fact that there are programs that rely on atime, so distributions don't want to set the default mount option on a filesystems to noatime.

      For the vast majority of users who aren't interested in screwing around with their filesystem (and don't even know what a filesystem IS), that means that they'll suffer this performance penalty. That's why this middle ground
      • Re: (Score:3, Insightful)

        by Rob Simpson ( 533360 )
        Or the more user-friendly distros could just pose a simple question in plain english, like in ArcherB's post [slashdot.org]:

        "Do you wish to log whenever a file is written or read? So every time a file is used, it has to write an entry on the HDD, slowing performance, but it can have uses, like in forensics, security or backups (if a file has not been read in three years, it's probably safe to archive and move off the drive)."

        With the default answer being "no" and only a single click required to make it "yes".
        • by Fred Ferrigno ( 122319 ) on Wednesday August 08, 2007 @07:48PM (#20163995)
          That's a really silly question to ask the user at install. If you had to answer all questions of that level of significance, it would take forever. ("Do you want version 0.8.5 of this library or 0.9.1? 0.9.1 has more features but is less compatible...") Let the distro pick a sensible default and have users who know or care about it change it later for themselves.

          The only real question is whether noatime or relatime make for a more sensible default.
    • by Yokaze ( 70883 ) on Wednesday August 08, 2007 @05:54PM (#20162945)
      No, it is not overblown, because, as Alan Cox put it:

      Ext3 currently is a standards compliant file system. Turn off atime and its very non standards
      compliant, turn to relatime and its not standards compliant but nobody will break (which is good)

      It is no option for the kernel to make noatime standard, as it would brake POSIX compliance. But without noatime, the OS suffers a large penalty compared to some other OSs. The magnitude of the penalty has been made clear in the quote from the article.
      So a solution, which is POSIX compliant, but doesn't suffer as much a penalty as the current solution is sought for.
    • For filesystems like /tmp, and /usr (maybe /var if it gets a lot of read traffic), noatime is probably a good idea. For the last few years, however, most Linux distributions have discouraged having multiple partitions, making it much harder to do this kind of tuning.
      • by Maltheus ( 248271 ) on Wednesday August 08, 2007 @06:35PM (#20163325)
        For the last few years, however, most Linux distributions have discouraged having multiple partitions

        Really? I can't see why. In the past, I didn't really see the point of multiple partitions but with the choice of filesystems now, they make a huge difference. Putting my /usr/portage (Gentoo) dir in a separate ReiserFS partition makes system updates a lot faster. And dealing with large video files on anything less than XFS is a slow PITA, especially when trying to delete the associated transcoding temp files. Maybe these things don't affect the average user much, but computers are never fast enough for me and I'll take what I can get.
  • In the various BSD flavors you can mount volumes "noatime", which is generally safe and does a pretty good job of keeping things moving. If you really need atime updates you can always remount the volume, but frankly not many people use it from what I've seen (maybe tail -f?).
    • Re: (Score:3, Informative)

      by PalmKiller ( 174161 )
      Yes its there...I use noatime on many linux servers. Most definetly use it where news and maildir type mail folders are mounted.

      For instance on the mail server do this in the fstab (not necessary on root and the like...just use it on the heavy traffic mounts): /dev/sda2 /var/spool ext3 noatime 1 2 /dev/sdb1 /home ext3 noatime,usrquota 1 2
    • Re: (Score:2, Informative)

      if the file is appended, the ctime will be updated. the BSD tail checks for an inode change or a decrease in filesize (and reopens in that case). Otherwise, the file descriptor is kept open and continually read from. When new data is written to the file, it will be available for reading automatically.
    • Re: (Score:3, Interesting)

      by DrXym ( 126579 )
      In the various BSD flavors you can mount volumes "noatime", which is generally safe and does a pretty good job of keeping things moving. If you really need atime updates you can always remount the volume, but frankly not many people use it from what I've seen (maybe tail -f?).

      I wish Unix (including Linux) would be more proactive about culling options which are not used by the majority and have such a detrimental effect. If the disk performance leaps by 10% by not using atime, it seems a no-brainer that no

      • for tracking which files are no longer used. That is why backup utilities such as tar have a --preserve-atime option to avoid updating atime during a backup. The proposed relatime option preserves the function of finding files no one uses anymore - for that purpose, 1 day resolution is fine. HSM systems depend on atime to know what to archive. Again, 1 day resolution is fine for that purpose.
  • mount noatime? (Score:2, Redundant)

    by twitter ( 104583 )

    man mount says:

    noatime

    Do not update inode access times on this file system (e.g, for faster access on the news spool to speed up news servers).

    Is there something I'm missing?

    • And then I read the article. Very intersting, but the noatime trick will work till they get realtime sorted out. (unless you use mutt)

    • Re:mount noatime? (Score:4, Informative)

      by bugnuts ( 94678 ) on Wednesday August 08, 2007 @05:22PM (#20162621) Journal

      Is there something I'm missing?
      Nope, it's something everyone else has been missing and apparently what's obvious to sysadmins is not obvious to the world. I do like the relatime option, though.

      atime updates actually help a LOT in some circumstances. I use it to help with security checks (even though you can hack the atime record), to help debug (what input file caused it to hang?), and all sorts of things where it's useful to know when a file was read.

      I could cope with not having them, but in many cases I love the extra information atime gives.
  • by Marxist Hacker 42 ( 638312 ) * <seebert42@gmail.com> on Wednesday August 08, 2007 @05:14PM (#20162509) Homepage Journal
    And, for every file that is already cached and which we read from the cache ... do a write to the disk!'

    Uh, why? Or rather, why not cache the atime update until disk usage is clear, THEN do the write, at least for already cached files?
    • by Graff ( 532189 )
      Exactly what I was thinking, wouldn't it be smart if all of the access times were just cached and then updated in one write? I mean why do 100 small writes when you are in the middle of a bunch of reads when you can just gather up all the access times and write them in a burst.

      It just seems like common sense to me. Yes, access times can be useful data but I think they are minor enough not to be done immediately. I'd default to having them cached and have an option for them to be applied immediately for t
  • by JbirdUAH ( 104470 ) on Wednesday August 08, 2007 @05:17PM (#20162545)
    if the poster had read the article they would have noticed that Linus did not say those things that are quoted - Ingo Molnar did.
  • atime vs ctime (Score:5, Insightful)

    by Intron ( 870560 ) on Wednesday August 08, 2007 @05:19PM (#20162567)
    Amazingly, standard Unix filesystems keep time of last access (atime), change of status (ctime), and file modification (mtime) but do not remember when the file was first created, which is something I have frequently wished for.
    • Re: (Score:3, Interesting)

      by clem ( 5683 )
      Well, add enough features and a filesystem begins to look like a source control system. I don't see any advantage by having file creation times tracked by the kernel -- better to do it in user space.
    • Re:atime vs ctime (Score:5, Interesting)

      by EvanED ( 569694 ) <<moc.liamg> <ta> <denave>> on Wednesday August 08, 2007 @06:24PM (#20163229)
      There is a technical reason for this.

      A lot of the time, modification of a file... isn't a modification of a file. Instead, the program will delete the existing file and create a new one in its place. (There is sometimes other operations in there, like saving to a temp file, deleting the original, then renaming the temp file to the original file name.)

      This means that storing the real creation time of a file means that it won't be what you expect, because the file that you think is the same file actually isn't.

      (MS-DOS/Windows have something called filesystem tunneling [msdn.com] to attempt to get around this problem. If a file is deleted and a new one created in its place (see the MSDN article linked to from there for details) within a default 15 seconds, the creation time of the old file is carried over. This technique exchanges purity and absolute correctness (not that metadata times are reliable against tamper anyway) for utility.)
      • Re:atime vs ctime (Score:5, Interesting)

        by EvanED ( 569694 ) <<moc.liamg> <ta> <denave>> on Wednesday August 08, 2007 @06:29PM (#20163275)
        I know self-replies are stupid, but I should have mentioned something else. The metadata tunneling that Windows does is much more important than it is on Unix because the filename may need to be tunneled as well. If you open a file called "somefile with a long name.txt" in an old DOS program by opening SOMEFI~1.TXT (or even in a recent program) and it does this delete/create thing, you don't want the OS to say "oh, you're making a new file called SOMEFI~1.TXT. Spiffy"; you need the original "somefile with a long name.txt" name to carry over.

        The linked site explains all this, but I know the propensity of /. readers (myself included) to RTFA. ;-)
    • NTFS (Score:4, Insightful)

      by inKubus ( 199753 ) on Wednesday August 08, 2007 @06:38PM (#20163365) Homepage Journal
      NTFS has last access also (on by default).

      You can disable it in a few different ways

      fsutil behavior set disablelastaccess 1
      Once this is done, the Last Access Time attribute for newly created files will simply be their File Creation Time. Disabling Last Access Time may affect the operation of backup programs that use the Remote Storage service. YMMV

      Or there's a registry key, which requires a reboot:

      System Key: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contr ol\FileSystem]
      Value Name: NtfsDisableLastAccessUpdate
      Data Type: REG_DWORD (DWORD Value)
      Value Data: (0 = disable, 1 = enable)
      • Re: (Score:3, Informative)

        by shird ( 566377 )
        This setting appears to be disabled by default on Vista. (ie atime is not set). Which makes sense with the amount of thumbnail viewing that goes on in that OS.
  • WTF? I think I get it now, but I didn't until I started reading the comments... But how about someone give a synopsis for the non kernal hackers here.
    • Re:Summary please? (Score:5, Informative)

      by mpeg4codec ( 581587 ) on Wednesday August 08, 2007 @05:25PM (#20162647) Homepage
      File access timestamps, by default, are updated each time a file is read, and this occurs a write to the disk. Even if a file resides in cache, a write must be performed every time it is opened [even though the cache prevents a read from the disk]. A few people found that by disabling this, performance increases dramatically. The long and short of it: use noatime when you're mounting a file system [or in the fstab] if you want to try for yourself.
  • Why should atime updates have to be written out to disk immediately? It probably isn't the end of the world if a few get lost if a filesystem doesn't get unmounted cleanly, and it probably updates a *lot* more frequently than anything else in the inode, so why not just have the filesystem keep the atimes separately from the rest of the metadata somewhere? It would only take a little bit of space to hold all the atimes on most filesystems (4 bytes per atime times say 250,000 files plus 5% for indexing over
    • Re: (Score:3, Informative)

      by slew ( 2918 )
      I think lazy-atime already keeps a dirty cache of atimes.

      I think relative-lazy-atime optimizes this further by only scheduling updates for atime if the old atime is older than ctime or mtime. If the old atime is newer than ctime or mtime then it silently forgets if you've accessed the file. If you are updating ctime or mtime, then I think atime is updated anyhow.

      This optimization still allows certain programs to tell if files have been read once since they were last modified (probably the only non-securit
  • Note that this story has nothing to do with real-time systems, contrary to what I thought when I read the title.

    If you read carefully, you will see it says rELAtime, not rEALtime.
  • I found that mounting using the noatime option on Solaris 8 and later was good for performance on filesystems which I mirrored via rsync. For example we had a cvs server that was struggling a little to keep up because rsyncing the files out to the mirrors was expensive. Changing its filesystem options to include noatime meant that a lot of the unnecessary I/O disappeared (previously I guess the very act of checking if a file had changed would have incurred a disk write, and we were syncing every all the fil
  • If ever there were a time to bring it back...
  • The update part of the "locate" utility bugs me. First time that thing went off when I was at the PC, causing all kinds of mysterious disk activity, I thought I'd just been hit by a virus. Now I make sure to remove "locate" entirely from all my systems. Wonder how much "noatime" would help? I'd probably still keep "locate" off my systems.
    • Re: (Score:2, Informative)

      by Skater ( 41976 )
      No.

      You could schedule the update (updatedb) to run at a more convenient time.

      Locate is a pretty useful command - locate file, and it shows you instantly where it is. I don't use it a lot but when I do it's VERY handy to have.
  • Wow (Score:3, Insightful)

    by quantum bit ( 225091 ) on Wednesday August 08, 2007 @05:55PM (#20162959) Journal
    I can't believe this is even an issue. I've been mounting everything noatime on my BSD systems for ages. The only thing I can think that it might possibly be used for are scripts that purge /tmp of files that haven't been accessed in a while. Even for that, ctime or mtime isn't a bad compromise.

    Bit of trivia -- NTFS does the exact same thing with regards to access times. There's a registry entry to disable it buried somewhere deep that I don't remember at the moment, but if you're stuck on Windows it might be worth looking up to improve I/O performance.
    • Re: (Score:3, Informative)

      by dj_tla ( 1048764 )
      Good point! Here's how to turn it off:

      fsutil behavior set disablelastaccess 1
      Or if you just have to hack the registry:

      Hive: HKEY_LOCAL_MACHINE
      Key: SYSTEM\CurrentControlSet\Control\FileSystem
      Name: NtfsDisableLastAccessUpdate
      Type: REG_DWORD
      Value: 1
    • Re: (Score:3, Informative)

      Bit of trivia -- NTFS does the exact same thing with regards to access times. There's a registry entry to disable it buried somewhere deep that I don't remember at the moment, but if you're stuck on Windows it might be worth looking up to improve I/O performance.


      Bit of additional trivia, Vista already disables it by default, and the whole access timestamp mechanism has changed, removing this performance penalty all together.
  • by Ingo Molnar ( 206899 ) on Wednesday August 08, 2007 @06:16PM (#20163155) Homepage

    Hey, Slashdot posted an article about me! [ They also renamed me to Linus - what more can a geek ask for? ;-) ]

    In any case, the latest version of the better-relatime patch can be picked up from:

    http://redhat.com/~mingo/relatime-patches/

    Apply it, build it, reboot into the new kernel and enjoy a faster (and lower latency) desktop. (no fstab twiddling needed)

    • by Anonymous Coward on Wednesday August 08, 2007 @06:35PM (#20163331)
      I agree - modifying a text file is a messy complicated business only suitable for the elite super hackers out there. It's much simpler for me to apply the patch and recompile the kernel.

      I kid, I kid.
      • by Ingo Molnar ( 206899 ) on Wednesday August 08, 2007 @07:06PM (#20163603) Homepage

        I agree - modifying a text file is a messy complicated business only suitable for the elite super hackers out there. It's much simpler for me to apply the patch and recompile the kernel.

        I kid, I kid.

        ok, you are kidding, but i'll still bite :-)

        Firstly, the patch is mainly about modifying relatime behavior to make it more compatible and more usable.

        The fact that you dont have to change fstab is no big deal, provided you have the right util-linux package installed, with the relatime user-space patch applied which not even the latest distro devel repositories have included.

        If you dont have that then adding "relatime" to your fstab might leave you with a read-only mounted root filesystem and some commandline (or rescue-image) tinkering to do.

        People prefer all-in-one kernel patches that just turns on the feature they are interested in. You'd be surprised how many people are willing to try almost arbitrary kernel patches but loathe to touch their user-space environment in any way.

        And ... it's also kind of ironic that this relatively small patch often brings more practical benefits to the desktop than all the "big" desktop interactivity/latency features (cfs, swap-prefetch, -rt kernel) combined.

        Ingo^H^H^H^H Linus

        • Re: (Score:3, Interesting)

          by 12357bd ( 686909 )

          And ... it's also kind of ironic that this relatively small patch often brings more practical benefits to the desktop than all the "big" desktop interactivity/latency features (cfs, swap-prefetch, -rt kernel) combined.

          Talking a bout desktop interactivity, it seems you missed to mention Con's scheduler in gamming scenarios, curious eh?.

  • How does Mac OS X handle atime? Is their a noatime option?
  • by grims ( 602269 ) on Wednesday August 08, 2007 @06:33PM (#20163309)
    On of my gripes with Linux is that one cannot spin down the disks to lessen their wear and tear.
    Ive been told that the kernel constantly needs to access the disk...

    Is this the reason of something else prevents the disks from spinning down?
    • by rahvin112 ( 446269 ) on Wednesday August 08, 2007 @07:34PM (#20163875)
      Stopping and Starting a disk causes the most wear on the disk. When in an idle state the spinning disk has fully lubricated bearings and is using just a tiny amount of energy. Strap in a stop and start and you have bearings on start that don't have their lubrication optimally spread (gravity and lack of motion cause the metal to get closer together and depending on the manufacturer may have some of the bearings without lubrication), and the spinup of the disks themselves is on average a 6W draw (idle is like .3W). Plus, when the disks are fully spinning wobble is going to be constrained a bit by the speed, whereas on startup and stopping the minor imperfections in the disk can let the minor wobbles show which strains the bearings and causes wear and tear. See if the bearings start to fail and are say 20% shot, the motor on the drive can just use a little more energy to drive them, but the startup cost might exceed what the motor is capable of outputing. Using the example above, the .3W draw on idle might climb to .6W, but on startup that could translate in moving from 6W to 12W (and exceeding what the motor can physically provide).

      And if you don't believe any of that you shouldn't have any trouble using google to find Admins who tell horror stories about having to reboot a drive and losing the entire drive because the bearings were shot to the point that once the disks stopped the motor couldn't generate enough force to restart them. But the disk could have lasted years more as long as it wasn't stopped. In fact in companies where a lot of data is stored the disks are put on their own power source at least partially because the disks don't have to be stopped if a server needs to be rebooted because of failure or updates. This is also one of the reasons to be wary of purchasing used storage arrays. Might have worked great when they shut it off, but you might be able to restart the array.
    • Re: (Score:3, Informative)

      by dbIII ( 701233 )
      I've never bothered to do this but I have talked to people who have and there are a few options.

      Syslog is often the culprit so if you can get it to stop writing log files all the time your disk can sleep longer. There is a syslog out there somewhere that limits it's writes to disk to when it fills a cache - the quick hack otherwise with an unchanged system is to get it to dump logs to a ram disk (kernel parameter on boot to enable ram disks) and sync every day or whenever.

      Another thing is cron - work out

  • by redelm ( 54142 ) on Wednesday August 08, 2007 @06:37PM (#20163357) Homepage
    Unless I have strong reason otherwise, I put `noatime` in /etc/fstab options column for all filessystems, including especially / .

    Problem solved. Many older/slower machines [laptops] can be sped up considerably by this step.

  • by Trogre ( 513942 ) on Wednesday August 08, 2007 @07:02PM (#20163573) Homepage
    (mount ext3 filesystem with noatime flag)

    $ time for i in `seq 1 10000`; do touch file1.dat; done

    real 0m15.231s
    user 0m3.075s
    sys 0m11.970s

    $ time for i in `seq 1 10000`; do cat file1.dat >>/dev/null; done

    real 0m14.326s
    user 0m2.928s
    sys 0m11.172s

    (remount without noatime flag)

    $ time for i in `seq 1 10000`; do touch file1.dat; done

    real 0m12.629s
    user 0m2.687s
    sys 0m9.772s

    $ time for i in `seq 1 10000`; do cat file1.dat >>/dev/null; done

    real 0m12.401s
    user 0m2.624s
    sys 0m9.624s

    Yes I think I'll stick with atime for now, thanks Linus.

  • by mi ( 197448 ) <slashdot-2017q4@virtual-estates.net> on Wednesday August 08, 2007 @07:44PM (#20163969) Homepage Journal

    But sometimes you need it... Whether it is to project your savings or to figure out, if a particular file was read within the last year.

    My problem with atime is that it is not universal enough. For example, reading a file via mmap() or sending it directly to a socket via sendfile() (both methods widely used by web-servers) will not update its atime. The access-timestamp should be updated every time a file is opened for reading, rather than when a read() is issued on it...

    So, when I wanted to report, when my little piece of software was last downloaded (via HTTP), I could not, unfortunately, rely on the file's atime...

"Conversion, fastidious Goddess, loves blood better than brick, and feasts most subtly on the human will." -- Virginia Woolf, "Mrs. Dalloway"

Working...