Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758726AbZDWOLZ (ORCPT ); Thu, 23 Apr 2009 10:11:25 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756330AbZDWOLH (ORCPT ); Thu, 23 Apr 2009 10:11:07 -0400 Received: from thunk.org ([69.25.196.29]:50057 "EHLO thunker.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755170AbZDWOLF (ORCPT ); Thu, 23 Apr 2009 10:11:05 -0400 Date: Thu, 23 Apr 2009 10:10:06 -0400 From: Theodore Tso To: Jeff Garzik Cc: Jamie Lokier , Andrew Morton , Valerie Aurora Henson , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Chris Mason , Eric Sandeen , Ric Wheeler , Jens Axboe Subject: Re: [RFC PATCH] fpathconf() for fsync() behavior Message-ID: <20090423141006.GH2723@mit.edu> Mail-Followup-To: Theodore Tso , Jeff Garzik , Jamie Lokier , Andrew Morton , Valerie Aurora Henson , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Chris Mason , Eric Sandeen , Ric Wheeler , Jens Axboe References: <20090423001257.GA16540@shell> <20090422221748.8c9022d1.akpm@linux-foundation.org> <20090423112105.GA1589@shareable.org> <20090423124230.GF2723@mit.edu> <49F06381.3090605@garzik.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49F06381.3090605@garzik.org> User-Agent: Mutt/1.5.18 (2008-05-17) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@mit.edu X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1306 Lines: 32 On Thu, Apr 23, 2009 at 08:48:01AM -0400, Jeff Garzik wrote: > Theodore Tso wrote: >> So we can create a more finer-grained controlled system call --- >> although I would suggest that we just add some extra flags to >> sync_file_range() --- but it's doubtful that many application >> programmers will use it. > > sync_file_range() seems the obvious avenue for new fsync flags. > > I even explored what it would take to add a "flush storage dev writeback > cache, for this file" flag to sync_file_range(), rather unfortunately > non-trivial given the current implementation's close ties to MM. What I had roughly in mind was some (optional) calls to the filesystem before and after the current implementations MM magic, but I haven't thought very deeply on the subject yet, mainly because... > But yeah... how many people will use these fancy new flags and features? > Yeah. That issue. It would be nice to have some additional semantics, but in terms of priorities, it's not the highest thing on my list in terms of itches to scratch. - Ted -- 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/