New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider mounting /rw with "noatime" mount flag #2933

Open
cfcs opened this Issue Jul 20, 2017 · 0 comments

Comments

Projects
None yet
2 participants
@cfcs

cfcs commented Jul 20, 2017

Qubes OS version (e.g., R3.2):

R3.2

Affected TemplateVMs (e.g., fedora-23, if applicable):

fedora-23 and debian-8, also / in dom0


Expected behavior:

Unnecessary disk writes are kept to a minimum, ie /rw being mounted with -o noatime.

Actual behavior:

Atime for every inode in every vm is updated often because /rw is mounted relatime.

Steps to reproduce the behavior:

mount | grep '^/' | fgrep --color time

General notes:

from man mount:

       relatime
              Update  inode  access  times  relative to modify or change time.
              Access time is only updated if the previous access time was ear‐
              lier  than  the  current  modify  or  change  time.  (Similar to
              noatime, but it doesn't break mutt or  other  applications  that
              need  to know if a file has been read since the last time it was
              modified.)

              Since Linux 2.6.30, the kernel defaults to the behavior provided
              by   this   option  (unless  noatime  was  specified),  and  the
              strictatime option is required to obtain traditional  semantics.
              In  addition, since Linux 2.6.30, the file's last access time is
              always updated if it is more than 1 day old.

So this means that every day, fgrep -r or git grep will update metadata on everything they touch, resulting in a large amount of writes, which in turn means more data to backup every day. I personally believe atime is pretty useless, but if there are arguments for this, please do speak up!


Related issues:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment