From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755603AbYAWWcZ (ORCPT ); Wed, 23 Jan 2008 17:32:25 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754838AbYAWWcK (ORCPT ); Wed, 23 Jan 2008 17:32:10 -0500 Received: from extu-mxob-2.symantec.com ([216.10.194.135]:51297 "EHLO extu-mxob-2.symantec.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754744AbYAWWcI (ORCPT ); Wed, 23 Jan 2008 17:32:08 -0500 Date: Wed, 23 Jan 2008 22:29:49 +0000 (GMT) From: Hugh Dickins X-X-Sender: hugh@blonde.site To: Linus Torvalds cc: Miklos Szeredi , a.p.zijlstra@chello.nl, salikhmetov@gmail.com, linux-mm@kvack.org, jakob@unthought.net, linux-kernel@vger.kernel.org, valdis.kletnieks@vt.edu, riel@redhat.com, ksm@42.dk, staubach@redhat.com, jesper.juhl@gmail.com, akpm@linux-foundation.org, protasnb@gmail.com, r.e.wolff@bitwizard.nl, hidave.darkstar@gmail.com, hch@infradead.org Subject: Re: [PATCH -v8 3/4] Enable the MS_ASYNC functionality in sys_msync() In-Reply-To: Message-ID: References: <12010440803930-git-send-email-salikhmetov@gmail.com> <1201044083504-git-send-email-salikhmetov@gmail.com> <1201110066.6341.65.camel@lappy> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 23 Jan 2008, Linus Torvalds wrote: > On Wed, 23 Jan 2008, Miklos Szeredi wrote: > > > Sure, I would have though all of this stuff is 2.6.25, but it's your > > kernel... :) > > Well, the plain added "file_update_time()" call addition looked like a > trivial fix, and if there are actually *customers* that have bad backups > due to this, then I think that part was worth doing. At least a "sync" > will then sync the file times... Fair enough. Something I dislike about it, though, is that it leaves the RAM-backed filesystems (ramfs, tmpfs, whatever) behaving visibly differently from the others. Until now we've intentionally left them out of syncing and dirty accounting, because it's useless overhead for them (one can argue whether that's quite true of tmpfs overflowing out to swap, but that's a different debate). So they won't be getting these faults on shared writable, so their file times won't get updated in the same way. But I guess that's an aesthetic consideration, of less significance than bad backups - assuming not many people use backups of tmpfs. Hugh