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 Content-Length: 1336 Lines: 30 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 -- 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/