Subject: O_NOATIME

From: Ron Mayer <[email-masked]>
Date: Thu, 03 Aug 2006 13:35:14 -0700

Would people be interested in a trivial patch that adds O_NOATIME
to open() for platforms that support it?  (apparently Linux 2.6.8
and better).

It seems to work here, feels harmless to me (an easy ifdef to
check if it's there), and seems it would theoretically help,
though I don't notice a consistent difference (I guess I"m not
thrashing my disks hard enough?).   Are there any open()s where
we don't want NOATIME if available?

---

From: Tom Lane <[email-masked]>
Date: Thu, 03 Aug 2006 16:38:24 -0400

> to open() for platforms that support it?  (apparently Linux 2.6.8

Isn't that usually, and more portably, handled in the filesystem
mount options?

			regards, tom lane

---

From: Ron Mayer <[email-masked]>
Date: Thu, 03 Aug 2006 13:52:28 -0700

> Isn't that usually, and more portably, handled in the filesystem

Yes to both.  I could imagine that for small systems/workstations
you might have some files that want access time, and others that
wanted NOATIME -- it seems the new flag lets you choose on a
file-by-file bases.

That's why I asked.  I imagine it won't help on any well-administered
production server since they'd probably mount the whole filesystem
that way; but might help a bit on out-of-the-box-default-config
benchmarks done by naive users who don't tweak filesystem settings.

Don't know if we'd care about such an audience or not.

---

From: Tom Lane <[email-masked]>
Date: Thu, 03 Aug 2006 17:06:28 -0400

> wanted NOATIME -- it seems the new flag lets you choose on a

Personally, if I were an admin who wanted access times, I'd regard
the existence of such a flag as a security hole.

			regards, tom lane

---

From: Ron Mayer <[email-masked]>
Date: Thu, 03 Aug 2006 14:31:50 -0700

> the existence of such a flag as a security hole.

I'm not sure I see that.  I'd have thought since postgresql
already caches stuff in shared buffers, the atime of a postgresql
file isn't reliable anyway; and outside of postgresql O_NOATIME
doesn't seem to me to affect admins any worse the existence of utime().

OTOH, I'm not going to argue for the patch either.  I think it'd
be fair to say adding a linuxism and only benefiting novice/casual
users isn't that exciting.