From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rik van Riel Subject: Re: RFC: O_PONIES semantics (well O_REWRITE) Date: Wed, 17 Jun 2009 09:52:07 -0400 Message-ID: <4A38F507.4050104@redhat.com> References: <4A3057DD.1050703@redhat.com> <20090611055309.GR9002@webber.adilger.int> <4A310F73.6080608@redhat.com> <1244730231.5047.11.camel@heimdal.trondhjem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Andreas Dilger , linux-fsdevel , Ray Strode , elb@psg.com To: Trond Myklebust Return-path: Received: from mx2.redhat.com ([66.187.237.31]:50084 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932223AbZFQNzW (ORCPT ); Wed, 17 Jun 2009 09:55:22 -0400 In-Reply-To: <1244730231.5047.11.camel@heimdal.trondhjem.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Trond Myklebust wrote: > How is this any different than just having your application use > mkostemp() to create a temporary dot file, then renaming it when done > writing? That is exactly what it is. There are reasons for implementing it at a lower level in the system, though. Implementing it in glibc: - means applications get it right (today, many don't) - allows for a performance optimization, moving the fsync into a specially spawned off temporary thread, so the main application doesn't stall Implementing it in the kernel allows for some further performance and power optimizations, most notably: - the sync could be turned into an ordering requirement, meaning it can be postponed and even obsoleted by a future version of the file - the ability to postpone the write allows for better power saving -- All rights reversed.