From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dongsheng Yang Subject: Re: [PATCH RESEND] ubifs: Introduce a mount option of force_atime. Date: Fri, 26 Jun 2015 15:13:26 +0800 Message-ID: <558CFB96.2000006@cn.fujitsu.com> References: <1433831809.28854.17.camel@sauron.fi.intel.com> <55769D97.3010602@nod.at> <5577AC03.9060909@cn.fujitsu.com> <1433928078.14092.1.camel@sauron.fi.intel.com> <55780D1C.6080907@cn.fujitsu.com> <1433931934.14092.11.camel@sauron.fi.intel.com> <557812A4.8020409@cn.fujitsu.com> <1433934324.14092.15.camel@sauron.fi.intel.com> <55892D18.3020203@cn.fujitsu.com> <1435056240.7659.69.camel@sauron.fi.intel.com> <20150624003335.GG22807@dastard> <558BD010.6020207@cn.fujitsu.com> <1435226918.9627.14.camel@sauron.fi.intel.com> <558BD3B0.8080209@cn.fujitsu.com> <1435231689.9627.17.camel@sauron.fi.intel.com> <558CA82B.7050306@cn.fujitsu.com> <1435302083.9627.36.camel@sauron.fi.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Cc: Dave Chinner , Richard Weinberger , , , To: Return-path: Received: from cn.fujitsu.com ([59.151.112.132]:7992 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1751717AbbFZHSg (ORCPT ); Fri, 26 Jun 2015 03:18:36 -0400 In-Reply-To: <1435302083.9627.36.camel@sauron.fi.intel.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 06/26/2015 03:01 PM, Artem Bityutskiy wrote: > On Fri, 2015-06-26 at 09:17 +0800, Dongsheng Yang wrote: ... > This means that if a file-system (e.g., UBIFS or JFFS2) never supported > atime, it is harder to add atime support without breaking the old > behavior. > > What if we push the two "set NOATIME flag" lines of code down to > individual file-systems, instead of having it at the VFS level? TO be sure I understand it correctly, do you mean pushing the flags parsing work to individual file-systems? Then we can set the default behavior in file-system itself. Yes, I explained one idea about it in my last mail to introduce a file_system_type::parse_options(). Then we can implement a callback in ubifs to do what we want. But there is another problem I called as problem 2 in my last mail. That we can not distinguish: -o - default behavior (*no atime*) -o atime - atime support Even in vfs, we can not distinguish them. They are made to same in userspace by utils-linux. There is an idea to solve it, introducing a MS_ATIME. But that's too costly I think. Yang > > ... snip ... > >> (d), But when I heard an idea about UBIFS_ATIME_SUPPORT from you. >> I get an idea 3. >> ======================idea 3 in ubifs========================= >> UBIFS_ATIME_SUPPORT is n, same with what ubifs did: >> -o - no atime >> -o atime - no atime >> -o noatime - no atime >> -o relatime - no atime >> -o strictatime - no atime >> -o lazyatime - no atime >> >> UBIFS_ATIME_SUPPORT is y, same with what generic is doing: >> -o - default behavior (relatime currently) >> -o atime - atime support >> -o noatime - no atime support >> -o relatime - relative atime support >> -o strictatime - strict atime support >> -o lazyatime - lazy atime support > > Yes, this is an option, I am just trying to explore other possibilities. > > . >