Mount our writeable partitions "noatime" |
||||
Issue descriptionAs part of some digging for handling low memory conditions better, sonny noticed in the stack trace that we were blocked updating the "atime" for an encrypted stateful partition. This brings up the question: why are we tracking the access time of the stateful partition? There is no use case in Chrome OS, is there? I believe we should turn on noatime for all rw partitions in Chrome OS. --- Note: I did track down a really old bug where someone was talking about this. Bug #184449 , which has no real details. It seems to indicate that people were with the atime attribute for rootfs (??), which makes not much sense to me since that partition is mounted read only (and thus, presumably, linux ignores the atime attribute). --- I also checked: as far as I can see our encrypted stateful has always been mounted with RELATIME. Here's where we first added mount-encrypted, for instance: https://chromium-review.googlesource.com/c/16889/ Prior to that, I'm not 100% sure where we used to mount the cryptohome directory, but I do know where we mounted stateful in the past: in /sbin/chromeos_startup. Doing a "git log --patch" of that file shows no mention of "atime". --- ...anyway, if someone knows why we shouldn't do this, please yell!
,
May 10 2017
,
May 10 2017
Easy enough to implement: https://chromium-review.googlesource.com/c/502171/ https://chromium-review.googlesource.com/c/502093/ ...does anyone have any ideas to really truly confirm that noatime is OK? Any chance that the sync team somehow uses this? ...or some type or chrome cache maintenance code?
,
May 10 2017
atime is mostly useless -- it's the last "access" time -- not the latest write or modification time A few old things like mutt or pine used to use it I think to tell what the latest unread message or something like that. If it weren't for those things, I think noatime would probably be the default. They came up with relatime to try to reduce the cost. relatime reduces the frequency of atime updates to when atime is older than modification or create time, but it looked like in the stack trace Doug posted there was an ecryptfs write that was triggering a read-modify-write on the underlying file and there was an atime update happening. I think that was probably because the underlying file's modification time was newer than the atime. I'm 99% sure chrome wouldn't use atime since that attribute isn't guaranteed to be there on all OSes -- like I don't know if Windows would support that.
,
May 10 2017
we should disable it on our systems if possible since we don't care about it
,
May 10 2017
OK, sounds like people are convinced that this is a sane thing to do, even if we don't think there's likely to be any massive performance gain compared to relatime. I'll plan to park things CQ+1 tomorrow sometime so someone can yell if they have some reason not to land this...
,
May 12 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform2/+/dd38677d2d3526872f82bf7f07407c59835dbfbc commit dd38677d2d3526872f82bf7f07407c59835dbfbc Author: Douglas Anderson <dianders@chromium.org> Date: Fri May 12 10:25:35 2017 init: Mount stateful_partition as noatime There is no Chrome OS use case where we care about the access time of files in the filesystem. Stop recording it, which should (hopefully) give us a performance win. BUG= chromium:721107 TEST=Boot up type "mount | grep noatime". Now has more entries. Change-Id: I532343d77449c3102b3fd47458488c8825214363 Reviewed-on: https://chromium-review.googlesource.com/502093 Commit-Ready: Douglas Anderson <dianders@chromium.org> Tested-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Sonny Rao <sonnyrao@chromium.org> Reviewed-by: Mike Frysinger <vapier@chromium.org> [modify] https://crrev.com/dd38677d2d3526872f82bf7f07407c59835dbfbc/init/chromeos_startup
,
May 12 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform2/+/738b64295729ea9f60eac696ee9f2b693c8762ec commit 738b64295729ea9f60eac696ee9f2b693c8762ec Author: Douglas Anderson <dianders@chromium.org> Date: Fri May 12 10:25:34 2017 cryptohome: Mount with noatime There is no Chrome OS use case where we care about the access time of files in the filesystem. Stop recording it, which should (hopefully) give us a performance win. BUG= chromium:721107 TEST=Boot up type "mount | grep noatime". Now has some entries. Change-Id: I9f3a9993d22cba4c1e6e2ec2a576eb070898160d Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/502171 Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Sonny Rao <sonnyrao@chromium.org> Reviewed-by: Mike Frysinger <vapier@chromium.org> [modify] https://crrev.com/738b64295729ea9f60eac696ee9f2b693c8762ec/cryptohome/mount-encrypted.c
,
May 12 2017
,
May 16 2017
Verified with version 60.0.3101.0/9557.0.0 dev-channel |
||||
►
Sign in to add a comment |
||||
Comment 1 by diand...@chromium.org
, May 10 2017Labels: -Pri-3 OS-Chrome Pri-2