From owner-freebsd-current@FreeBSD.ORG Thu Oct 21 13:02:27 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EBAFE16A4CE for ; Thu, 21 Oct 2004 13:02:26 +0000 (GMT) Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23D3543D1D for ; Thu, 21 Oct 2004 13:02:26 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd07.aul.t-online.de by mailout11.sul.t-online.com with smtp id 1CKca1-0008WP-02; Thu, 21 Oct 2004 15:02:09 +0200 Received: from Andro-Beta.Leidinger.net (TEGgMZZbge6Ju5OPG27XY08diNye2MOhzZ+IIWeNTahdaQw7ivn4Qp@[84.128.194.178]) by fmrl07.sul.t-online.com with esmtp id 1CKcZj-1Uxd680; Thu, 21 Oct 2004 15:01:51 +0200 Received: from Andro-Beta.Leidinger.net (localhost [127.0.0.1]) i9LD1mpa061063; Thu, 21 Oct 2004 15:01:48 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: (from www@localhost)i9LD1m2P061062; Thu, 21 Oct 2004 15:01:48 +0200 (CEST) (envelope-from Alexander@Leidinger.net) X-Authentication-Warning: Andro-Beta.Leidinger.net: www set sender to Alexander@Leidinger.net using -f Received: from wwwproxy-2.sns-felb.debis.de (wwwproxy-2.sns-felb.debis.de [53.122.192.14]) by netchild.homeip.net (IMP) with HTTP for ; Thu, 21 Oct 2004 15:01:47 +0200 Message-ID: <1098363707.4177b33bc4f9c@netchild.homeip.net> Date: Thu, 21 Oct 2004 15:01:47 +0200 From: Alexander Leidinger To: Dan Nelson References: <417538B9.7070001@club-internet.fr> <41755FAF.8080300@colleduc.ee> <53515.208.4.77.15.1098213002.squirrel@208.4.77.15> <20041019202047.GB83510@dan.emsphone.com> <1098276238.41765d8ebfc0b@netchild.homeip.net> <20041020170848.GA11073@dan.emsphone.com> In-Reply-To: <20041020170848.GA11073@dan.emsphone.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 / FreeBSD-4.10 X-Originating-IP: 53.122.192.14 X-ID: TEGgMZZbge6Ju5OPG27XY08diNye2MOhzZ+IIWeNTahdaQw7ivn4Qp@t-dialin.net X-TOI-MSGID: b24b221f-e601-4cc5-99d1-8a97df46f7cc cc: Ryan Sommers cc: "Jean-S~A\(c\)bastien P~A\(c\)dron" cc: Kalev Lember cc: freebsd-current@freebsd.org Subject: Re: Read-only ReiserFS support for FreeBSD 5.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 13:02:27 -0000 Zitat von Dan Nelson : > Yes, the rename itself is an atomic operation, but that doesn't help > you if SU has commited the "delete rc.conf" step but has not yet > committed the "write data for rc.conf.new" step. SU doesn't guarantee > that its updates will be done in chronological order, just that at no > point will the filesystem be inconsistent. The best solution is to SU operates on the meta-data, if you need synchronous semantics for your data-write operations, you have to change the mode of operation at mount time. The same applies to journalling filesystems which don't operate in synchronous mode for the user-data part of the filesystem (I don't know how reiserfs handles this). > fsync rc.conf.new before unlinking rc.conf to guarantee that it has > been committed to disk. Note that /usr/bin/install has the same issues Yes, and every application which relies on such semantics but doesn't fsync's the file(s) is broken (AFAIK some MTA's behave like this, and some do the right thing). /usr/bin/install can't know if a particular install needs such strict constraints, so it's not supposed to fsync on it's own. If the installation of a set of files fails (power failure or whatever), the entire installation has to be repeated to make sure everything is ok. If you have a case where you absolutely need to have such a semantic, you can do a sync on your own ("expensive" solution), or add a switch to install which tells it to fsync (I'm sure someone is wiling to commit such a patch). > (and forcing a sync in there would really slow it down). I've lost so > many files due to this that I run with kern.{meta,dir,file}delay set to > {5,6,7} to make the window as small as possible while still giving me > good performance. I suggest to switch to better hardware if you experience a lot of such failures (or teach the programs to do the right thing or configure the filesystems to operate in sync mode)... Bye, Alexander. -- http://www.Leidinger.net/ Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org/ netchild @ FreeBSD.org : PGP ID = 72077137 A closed mouth gathers no foot.