Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751882Ab1CNE1A (ORCPT ); Mon, 14 Mar 2011 00:27:00 -0400 Received: from cobra.newdream.net ([66.33.216.30]:54928 "EHLO cobra.newdream.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751190Ab1CNE06 (ORCPT ); Mon, 14 Mar 2011 00:26:58 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=newdream.net; h=date:from:to:cc :subject:in-reply-to:message-id:references:mime-version: content-type; q=dns; s=newdream.net; b=VvMiigqDlbuH0Hqkrmwen2PXt FnrixQYpeRAfpaArafOExe9ED7Oc1T9v/uA0+MjVOszSMLLVRfBMsqEuRh59UZgZ euPIwzPz1KMKVw51+ZdaBz9k7b+CAn0oWL46rBwjtxsLciiwvPiLVTwgx52coqM8 oaRkaGE3a8BZNjAfVk= Date: Sun, 13 Mar 2011 21:29:17 -0700 (PDT) From: Sage Weil To: Indan Zupancic cc: Greg KH , Jonathan Nieder , Arnd Bergmann , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, "Aneesh Kumar K. V" , akpm@linux-foundation.org, linux-api@vger.kernel.org, mtk.manpages@gmail.com, viro@zeniv.linux.org.uk, hch@lst.de, l@jasper.es Subject: Re: [PATCH v3] introduce sys_syncfs to sync a single file system In-Reply-To: <1e597aedd3d7825dcc0630b1cf2399fa.squirrel@webmail.greenhost.nl> Message-ID: References: <201103111255.44979.arnd@arndb.de> <20110311235607.GB15853@elie> <9446ab1a2315c0d2476c30f8315a0503.squirrel@webmail.greenhost.nl> <20110312021001.GA16833@elie> <20110312173217.GA24981@kroah.com> <1e597aedd3d7825dcc0630b1cf2399fa.squirrel@webmail.greenhost.nl> 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: 1869 Lines: 54 On Mon, 14 Mar 2011, Indan Zupancic wrote: > Everyone seems to want to add this new syncfs, but it's not even defined > what it does. "Same as sync, but only on one fs" is IMHO not good > enough, because sync's behaviour is pretty badly documented, and that's > a system call. How about the man page below? I tried to avoid the somewhat antiquated implementation specific terminology in the sync(2) man page. I think adding this functionality into sync_file_range(2) is forcing unrelated functionality into an existing interface; sync_file_range operates on _files_, not an entire file system. With each API addition it is more important to make the interface simple and intuitive than to minimize the size of our patches. IMO that's why a new syscall is preferable to, say, an equivalent ioctl. Thanks- sage .TH SYNCFS 2 2011-03-13 "Linux" "Linux Programmer's Manual" .SH NAME syncfs \- commit cached file system state to stable storage .SH SYNOPSIS .B #include .sp .B void syncfs(int fd); .SH DESCRIPTION .BR syncfs () flushes any cached data modifications to the file system containing the file referenced by the file descriptor .I fd to stable storage (usually a disk). This includes the results of any file modifications or other file system operations that have completed prior to the call to .BR syncfs(2). This is similar to .BR sync(2), but will commit changes for only a single file system instead of all mounted file systems. .SH ERRORS This function is always successful. .SH "SEE ALSO" .BR bdflush (2), .BR fdatasync (2), .BR fsync (2), .BR sync (2), .BR sync (8), .BR update (8) -- 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/