Re: Modifying file access time upon exec...

From: Dag-Erling Smørgrav (des_at_des.no)
Date: 05/27/05

  • Next message: Marc Olzheim: "Re: Re: Modifying file access time upon exec..."
    Date: Fri, 27 May 2005 21:19:15 +0200
    To: Marc Olzheim <marcolz@stack.nl>
    
    

    Marc Olzheim <marcolz@stack.nl> writes:
    > No, I'm saying that there are filesystems you wouldn't want to mount
    > with noatime (/tmp, /var/tmp, /var/mail, /var/spool/*) because some
    > software depends on the atime being adjusted.

    Any software that depends on the value of atime is broken by design.

    DES

    -- 
    Dag-Erling Smørgrav - des@des.no
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
    

  • Next message: Marc Olzheim: "Re: Re: Modifying file access time upon exec..."

    Relevant Pages

    • Re: Modifying file access time upon exec...
      ... > Hi Marc, Ken, ... I'm saying that there are filesystems you wouldn't want to mount ... Other than changing it so that the atime on executable ...
      (freebsd-arch)
    • Re: Modifying file access time upon exec...
      ... I'm saying that there are filesystems you wouldn't want to mount ... > Any software that depends on the value of atime is broken by design. ...
      (freebsd-arch)
    • Re: [PATCH 2/2] Make relatime default
      ... This makes the assumption that atime is not used, which may be true on your system but isn't on others. ... Other admins use it to identify unused files which are candidates for backup to offline media or the bit bucket. ... Let people who want that behavior specify it for existing filesystems, if you want to remove functionality from ext4 or btrfs or some thing place where people have no existing expectations, I still think it's wrong, but I couldn't say I think it might break anything. ... I did a patch a few years ago which only updated atime on open and write, and that worked about as well as relatime, the inode update on open is cheap, the head is already there, and it was only slightly slower than noatime. ...
      (Linux-Kernel)
    • Re: [PATCH 00/23] per device dirty throttling -v8
      ... relevant distro. ... atime selection is 100% policy and belongs into ... atimes because of the way the vfs-level mount flags API is designed. ... Instead of doing such a fugly kernel patch just talk to the handfull ...
      (Linux-Kernel)
    • Re: [PATCH 00/23] per device dirty throttling -v8
      ... atimes because of the way the vfs-level mount flags API is designed. ... gets marked dirty when we update atime. ... when we remove the inode from the inode cache, ... Unlike relatime, there's no user-visible change (unless the ...
      (Linux-Kernel)