Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752301AbbGNLus (ORCPT ); Tue, 14 Jul 2015 07:50:48 -0400 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:60954 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751680AbbGNLuq (ORCPT ); Tue, 14 Jul 2015 07:50:46 -0400 Date: Tue, 14 Jul 2015 13:50:43 +0200 From: Pavel Machek To: John Stoffel Cc: Sage Weil , Zach Brown , Dave Chinner , Alexander Viro , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org Subject: Re: [PATCH RFC] vfs: add a O_NOMTIME flag Message-ID: <20150714115043.GB31973@amd> References: <1430949612-21356-1-git-send-email-zab@redhat.com> <20150507002617.GJ4327@dastard> <20150507172053.GA659@lenny.home.zabbo.net> <21836.51274.843585.839614@quad.stoffel.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21836.51274.843585.839614@quad.stoffel.home> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1840 Lines: 41 > Sage> I think this is the fundamental question: who do we give the > Sage> ammunition to, the user or app writer, or the sysadmin? > > Sage> One might argue that we gave the user a similar power with > Sage> O_NOATIME (the power to break applications that assume atime is > Sage> accurate). Here we give developers/users the power to not > Sage> update mtime and suffer the consequences (like, obviously, > Sage> breaking mtime-based backups). It should be pretty obvious to > Sage> anyone using the flag what the consequences are. > > Not modifying atime doesn't really break anything except people who > think they can tell when a file was last accessed. Which isn't > critical (unless your in a paranoid security conscious place...) but > MTIME is another beast entirely. Turning that off is going to break > lots of hidden assumptions. > > Sage> Note that we can suffer similar lapses in mtime with fdatasync > Sage> followed by a system crash. And as Andy points out it's > Sage> semi-broken for writable mmap. The crash case is obviously a > Sage> slightly different thing, but the idea that mtime can't always > Sage> be trusted certainly isn't crazy talk. > > True, but after a crash... people expect and understand there might be > corruption in a filesystem. Umm. No; people do not expect anything newer than ext3 to get corrupted, ever. In fact, I did not know about fdatasync/crash. That's rather nasty surprise. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/