Thread: O_NOATIME

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?

Ron Mayer <rm_pg@cheapcomplexdevices.com> writes:
> 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).

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

Tom Lane wrote:
> Ron Mayer <rm_pg@cheapcomplexdevices.com> writes:
>> 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).
> 
> Isn't that usually, and more portably, handled in the filesystem
> mount options?

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.

Ron Mayer <rm_pg@cheapcomplexdevices.com> writes:
> Tom Lane wrote:
>> Isn't that usually, and more portably, handled in the filesystem
>> mount options?

> 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.

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

Tom Lane wrote:
> Ron Mayer <rm_pg@cheapcomplexdevices.com> writes:
>> Tom Lane wrote:
>>> Isn't that usually, and more portably, handled in the filesystem
>>> mount options?
> 
>> 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.
> 
> Personally, if I were an admin who wanted access times, I'd regard
> 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.