Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754878Ab1CLCwU (ORCPT ); Fri, 11 Mar 2011 21:52:20 -0500 Received: from mail-iy0-f174.google.com ([209.85.210.174]:65102 "EHLO mail-iy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753519Ab1CLCwS (ORCPT ); Fri, 11 Mar 2011 21:52:18 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Hg99EIl+tzLYAZ5yEuuIptnDgts2gXcCXG/jZqt1DhdGFodyHNmmtUTH+WxqvOX8/P HOX+dS5mCiSGOqors4a9kfmapHJWs7Ib5vYHxwaSFusa3WkJCRz2rHWI/H5vMjDiVwKA fYn+DvyNXOMW0jBMEAOjI8lCNlFdVqgSNZRvw= Message-ID: <4D7ADFDD.9080108@gmail.com> Date: Fri, 11 Mar 2011 21:52:13 -0500 From: Ric Wheeler User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc13 Thunderbird/3.1.7 MIME-Version: 1.0 To: Indan Zupancic CC: Arnd Bergmann , Sage Weil , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, "Aneesh Kumar K. V" , Jonathan Nieder , 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 References: <201103111255.44979.arnd@arndb.de> <4D7AC0FE.8070806@gmail.com> <1d4d1b7ae64da97f44cad0e2bda4f832.squirrel@webmail.greenhost.nl> In-Reply-To: <1d4d1b7ae64da97f44cad0e2bda4f832.squirrel@webmail.greenhost.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3904 Lines: 91 On 03/11/2011 08:33 PM, Indan Zupancic wrote: > On Sat, March 12, 2011 01:40, Ric Wheeler wrote: >> On 03/11/2011 06:45 PM, Indan Zupancic wrote: >>> On Fri, March 11, 2011 12:55, Arnd Bergmann wrote: >>>> On Friday 11 March 2011, Indan Zupancic wrote: >>>>>> http://marc.info/?l=linux-fsdevel&m=127970513829285&w=2 >>>>> The patch there seems much more reasonable than introducing a whole >>>>> new systemcall just for 20 lines of kernel code. New system calls are >>>>> added too easily nowadays. >>>> The only problem with adding new system calls is that we are stuck >>>> with the interface until the end of time, so we must be sure not >>>> to get it wrong. The same thing is true for any other interface >>>> such as ioctl or extensions to existing system calls. People usually >>>> get away with adding new ioctls more easily because it is less >>>> obvious when they are added. >>> Agreed. >>> >>> I'm not sure this feature is important enough to add. I can't really >>> think of a regular use case where this would be useful, generally >>> it's transparent on which mount files are. Add symlinks, and you >>> give users a lot of rope. Any user has to make sure that all the >>> files they want to sync are on the same file system. >>> >>> About the arguments against sync(2): >>> >>>> - On machines with many mounts, it is not at all uncommon for some of >>>> them to hang (e.g. unresponsive NFS server). sync(2) will get stuck on >>>> those and may never get to the one you do care about (e.g., /). >>> It would be better to fix NFS, or mount it with the fsc option (assuming >>> a sync will write to the local cache instead of hanging forever then). >>> >>>> - Some applications write lots of data to the file system and then >>>> want to make sure it is flushed to disk. Calling fsync(2) on each >>>> file introduces unnecessary ordering constraints that result in a large >>>> amount of sub-optimal writeback/flush/commit behavior by the file >>>> system. >>> You can use sync_file_range() on those files to schedule the writes >>> and then do the fsync(2) as usual (both on files and dirs). >>> >>> If there still is a good reason to implement this, please don't add it >>> as a new system call, but add it to sync_file_range(), as that seems >>> the best place for odd file synchronisation operations. >>> >>> Greetings, >>> >>> Indan >>> >>> >>> -- >> Hi Indan, >> >> I think that you missed the point of the extension. >> >> Ric > The point is clear, it's to synchronize a specific file system instead > of all of them. > > But actually doing that from a program is harder than it looks, because > programs work with files, not file systems. To make this feature useful > the program needs meta information it can't easily get. That was my first > point. > > The rest was just replying to the motivations given to add the feature. > If those motivations miss the point of the extension, don't blame me. > > If you want to add a new one, "I'd like sync /mounpoint to work", then > do so, but please tell what practical use that has, if you're not going > to unmount the thing soon after anyway. > > Other than this questionable use case, is there any other one that would > justify adding this extension? > > Greetings, > > Indan > Sage was pretty clear in stating the motivation which is the use case you think is questionable. Probably not interesting for consumer devices, but definitely extremely interesting in large servers with multiple file systems. In fact, we do it today as mentioned earlier in the thread - this simply exports that useful capability in a clean way. Ric -- 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/