From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve French Subject: IS_NOCMTIME and setting of ctime and mtime on remote servers Date: Mon, 29 Aug 2005 12:16:44 -0500 Message-ID: <431342FC.20708@austin.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from ms-smtp-01.texas.rr.com ([24.93.47.40]:37840 "EHLO ms-smtp-01-eri0.texas.rr.com") by vger.kernel.org with ESMTP id S1751124AbVH2RQt (ORCPT ); Mon, 29 Aug 2005 13:16:49 -0400 Received: from [192.168.0.3] (cpe-70-112-171-162.austin.res.rr.com [70.112.171.162]) by ms-smtp-01-eri0.texas.rr.com (8.12.10/8.12.7) with ESMTP id j7THGhH9005545 for ; Mon, 29 Aug 2005 12:16:46 -0500 (CDT) To: linux-fsdevel@vger.kernel.org Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org NFS is the only place that sets NOCMTIME on inodes in its fhget routine IIRC. What is the exact intent of this? Does it stay set (so mtime and ctime updates are never sent to the server) or does it get reset somewhere (I did not see where nfs turned it off so presumably even explicit sets of the time are ignored by default?)? I realize that some users would prefer that an fs never set the file times to the remote server (at least for the cifs and nfs cases I have heard this in past years) as the server will set them implicitly anyway (and it can help performance). For cached files the local times in the client's version of the inode could be used indefinately (at least while the file is cacheable on the client, continuing to hold the caching token/oplock). I saw a thread on bsd mailing list from a few years ago in which some users were asking for a mount flag (nocmtime) to turn off ctime and mtime updates for much the same reason.