Message-ID: <3B75C1B0.C299483C@berdmann.de>
Date: Sun, 12 Aug 2001 01:37:20 +0200
From: "Bernhard R. Erdmann" <be@berdmann.de>
MIME-Version: 1.0
To: Bram Moolenaar <Bram@moolenaar.net>
CC: Russell Cattelan <cattelan@thebarn.com>, Seth Mos <knuffie@xs4all.nl>,
   Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Re: vim file write mode on journaling fs.
References: <200108111521.f7BFLTS03169@moolenaar.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Bram Moolenaar wrote:
> 
> Russell Cattelan wrote:
> 
> > This isn't a matter of laziness or poor design it's a trade off.
> > If you want the benefits of delayed allocation/write then there has to
> > be a DELAY otherwise there would be much point,
> > if you want better data integrity in the event of a crash
> > then mount your filesystems O_SYNC and loose the performance.
> 
> There is no need for such a trade-off.  It is not difficult to detect that the
> harddisk isn't very busy and start writing out dirty data blocks then.  This
> doesn't cause a performance drop and greatly increases reliability.
> 
> It's certainly worth the effort to implement this.  The tests done by Seth
> show that this is a real, existing problem.
> 
> Don't look at this from the point of view of a person that knows what "delayed
> allocation/write" means, look at it from the point of view of a user.


Look what Steve Best from IBM's JFS group wrote about it:

Several other aspects of log-based recovery are of interest. First, JFS
only logs operations on meta-data, so replaying the log only restores
the consistency of structural relationships and resource allocation
states within the file system. It does not log file data or recover this
data to consistent state. Consequently, some file data may be lost or
stale after recovery, and customers with a critical need for data
consistency should use synchronous I/O.

(http://www-106.ibm.com/developerworks/library/jfs.html)