From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: RFC: O_PONIES semantics (well O_REWRITE) Date: Fri, 12 Jun 2009 03:07:38 +0100 Message-ID: <20090612020738.GD25550@shareable.org> References: <4A3057DD.1050703@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel , Ray Strode , elb@psg.com To: Rik van Riel Return-path: Received: from mail2.shareable.org ([80.68.89.115]:45100 "EHLO mail2.shareable.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753864AbZFLCHg (ORCPT ); Thu, 11 Jun 2009 22:07:36 -0400 Content-Disposition: inline In-Reply-To: <4A3057DD.1050703@redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Rik van Riel wrote: > The ext4 automatic-fsync-on-rename discussion has shown that > many applications simply Do It Wrong when it comes to rewriting > configuration files. I got the impression ext4 has automatic-fsync-on-rename-only-if-the-old-file-exists, which is a bit less reliable. By the way, the kernel has some generic support for O_SYNC and O_DSYNC, and generic MS_SYNC mount option. So I guess it could also have generic support for mount options "sync_on_rename" and "sync_on_close", instead of only doing it with ext4. For example, this came up recently on the linux-mtd list which deals with flash filesystems. The ext4-like behaviour is being considerd in a flash filesystem. So if it's that important, maybe it would be even better to make it a generic VFS mount option for all filesystems. > Some of the common failures are: > - program overwrites the old config file > - program writes a new file, but forgets to fsync before rename > - program writes the new file in /tmp, so the rename fails on > some systems > - program writes a new file and fsyncs, but forgets to give the > new file the same file ownership, permission and/or extended > attributes as the old file It's also really hard to do those things from shell scripts, so they are almost never done there. > Glibc has the advantage of it not being in the kernel, but > implementing it in-kernel might give us the opportunity for > performance enhancements, like reducing step (5) to merely > enforcing ordering between filesystem operations, instead > of requiring an fsync. I think the performance enhancement from order-without-sync might be useful, I'm not sure, but if so not just for this operation, which is still quite specialised. -- Jamie